cli-tri build has never passed: yosys is installed after the tests that need it

[gHashTag]

The build job in .github/workflows/cli-tri.yml has never passed. Not once
since the workflow was added: 11 runs on master, 11 failures, and across
every branch the workflow has ever run on the success count is 0 of 56.

The failure

From run 32336682228,
the head of master at b6cb1ec69:

[smoke-gate] SKIP: yosys not on PATH
[smoke-gate] complete (passed: false)
thread 'fpga::tests::test_smoke_gate_json_synthetic_verify_lean' panicked at cli/tri/src/fpga.rs:9977:9:
  smoke-gate synthetic verify-lean path failed: Err(smoke-gate did not pass all phases)
test result: FAILED. 155 passed; 1 failed

Cause: step ordering

ubuntu-latest ships no yosys. The workflow does install it — but the install
is a line inside the run block of the last step, and that step is ordered
after cargo test -p tri:

      - name: cargo test -p tri          # <- needs yosys, runs first
        run: cargo test -p tri

      - name: the CLI actually produces a report
        run: |
          set -uo pipefail
          sudo apt-get update -qq && sudo apt-get install -y -qq yosys   # <- too late

So at test time yosys is never on PATH. Deterministic, 100% of runs, by
construction. A failed step aborts the job, so the install step has in fact
never executed in any of the 11 runs.

Why the test is not the thing to change

cli/tri/src/fpga.rs builds the gate's verdict as a conjunction that includes
yosys_ok:

    let passed = bit_config_result.is_ok()
        && dry_run_sweep_ok
        && (!run_verify_lean || verify_lean_ok)
        && (!run_theorem_matrix || theorem_matrix_ok)
        && (!validate_lean_standalone || validate_lean_standalone_ok)
        && yosys_ok;

Relaxing that — treating "yosys absent" as "yosys fine" — would turn the check
green while asserting nothing about synthesis, which is the same
absence-is-not-a-value defect closed in #2285 and #2287. The test is correct to
demand the binary. The YAML is what is wrong.

Scope check: is yosys the only missing dependency?

Checked, because fixing one ordering bug and uncovering another helps nobody.
Within smoke_gate() (cli/tri/src/fpga.rs:5946-6350) there is no reference to
lake, python3 or nextpnr — yosys is the only external binary it spawns.
Of the other conjuncts, theorem_matrix_ok is a hardcoded true, and the
verify-lean phase is a pure-Rust synthetic fixture that writes and re-reads its
own JSON rather than invoking Lean. The run log corroborates this: the only
phase that reported anything other than OK was the yosys skip.

Fix

Hoist the install into its own named step placed before cargo test -p tri,
and drop the now-redundant inline copy from the last step. The inline line
installed yosys and nothing else, so it is removed in full rather than trimmed.
Every other step keeps its order and content.

[gHashTag]

Landed via #2303, and the ordering defect this issue describes is fixed and
verified: the install yosys step now runs before the tests, and the smoke gate
reports

[smoke-gate] yosys synthesis OK

where it previously reported SKIP: yosys not on PATH.

The build check is still red. Reporting that plainly rather than letting
this issue close as if CI were green.

The ordering was necessary but not sufficient

With yosys present, every phase the gate prints now reports OK -- bit-config,
dry-run sweep, verify-lean, yosys synthesis -- and the verdict is still
passed: false:

[smoke-gate] dry-run sweep report OK (8 variants)
[smoke-gate] verify-lean OK (source=synthetic, theorems present)
[smoke-gate] yosys synthesis OK
[smoke-gate] complete (passed: false)

I checked the bit-config phase first, since it is the one conjunct that prints
no explicit OK. It is not the problem -- running the audit against the demo
bitstream from master exits 0 with all five assertions passing:

ASSERTION OK: IDCODE=0x03636093
ASSERTION OK: SPI_BUSWIDTH=x1
ASSERTION OK: STARTUPCLK=CCLK
ASSERTION OK: OSCFSEL=0
ASSERTION OK: no CRC register writes

Root cause: dry_run_sweep_ok is never set

In cli/tri/src/fpga.rs the flag has exactly two mentions in the whole file:

6098:    let mut dry_run_sweep_ok = false;
6333:        && dry_run_sweep_ok

Declared false, read in the verdict conjunction, and never assigned true
anywhere. The sweep phase genuinely succeeds and prints its OK line, but
nothing records it, so passed cannot be true for any input. The gate is
unpassable by construction -- independently of yosys.

This is the same defect the code comment at line 6167 already documents for its
sibling flag:

run_verify_lean stayed a parameter and verify_lean_ok stayed a declaration
nothing ever set

verify_lean_ok was restored from 494e659d8; dry_run_sweep_ok was lost in
the same batch merge and missed.

The compiler has been saying so on every run

cargo test -p tri emits, and has always emitted:

warning: variable does not need to be mutable
6098 |     let mut dry_run_sweep_ok = false;

A mut that is never mutated is precisely the signature of an unset flag. The
evidence was in all 11 failing logs.

Not fixing it here: that is a source change in cli/tri/src/fpga.rs, outside
this issue's scope, and it wants its own issue and review rather than being
folded into a CI ordering fix. Flagging that unused_mut on a boolean feeding a
gate verdict is worth denying rather than warning -- this one was visible for 11
runs and read past every time.