docs: record the LowerSwitch ordering constraint it now relies on

[OlivierBBB]

Follow-up to #2095 — comments only, no behavioural change.

Why

bodyContainsOnlyBitEquality carries this justification:

Note that as we lowerSwitch later, this pattern can't arise from lowerSwitch, but only directly from .zkc program.

Two problems with it:

1. The first half is true only by pass ordering — which perf: don't factor skipIf when not required #2095 itself changed. Nothing enforces it, and nothing fails if it is broken again.

2. The second half is not accurate. The shape is not unique to hand-written .zkc:

   • LowerSwitch emits exactly it, one diamond per case (see its own doc: if x == 1 {b_1 = 1} else {b_1 = 0});
   • FactorLimbEqualities emits one per limb;
   • factorSkipIf, in the same file, emits it too (though its output is never re-examined, since factor[] is decided over the original vector).

   None of them reaches the check today — purely because all three run later in the pipeline.

What

• Reword the comment to state the dependency rather than an impossibility, and note that breaking it costs only an unnecessary factorisation, not correctness. (That is worth saying: it tells the next reader this is a perf guard, so a stale assumption here is cheap.)
• Add the new requirement to LowerSwitch's doc, next to the must run before register splitting note it already carries. That is where someone reordering the pass will actually look; without it, moving LowerSwitch back above FactorSkipConditions would satisfy every documented constraint while silently invalidating the reasoning in the other file — and nothing would fail to signal it.

Verification

Comment-only (the diff contains no non-comment lines). go build ./... and golangci-lint run pkg/zkc/... clean.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Documents a pass-ordering dependency in the ZkC VM transform pipeline, clarifying why certain “bit-select diamond” patterns are assumed not to appear when FactorSkipConditions runs (performance rationale, not correctness).

Changes:

• Updates the FactorSkipConditions commentary to explain that the “bit-select diamond” pattern is not unique to hand-written .zkc, and that ordering changes only affect performance.
• Extends LowerSwitch’s doc comment to record that it is expected to run after FactorSkipConditions in the compilation pipeline.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
pkg/zkc/vm/transform.go	Adds an ordering note to LowerSwitch’s documentation to capture its pipeline dependency.
pkg/zkc/vm/internal/transform/factor_skip_conditions.go	Rewords the “bit equality / diamond” comment to reflect actual sources of the pattern and ordering implications.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[letypequividelespoubelles]

comment is false - as I added one more condition to factor the skip If

[letypequividelespoubelles]

=>

// Nothing to factorize if the body of the skip is a bit equality like b = x == 0 ? 1 :0.
// Note that as we lowerSwitch later, this pattern can't arise from lowerSwitch, but only
// directly from .zkc program or other lowering steps (FactorLimbEqualities ...)