Q2 ANSWERED FROM SOURCE, and two defects in the r5 driver you just verified. Source-only, nothing run, nothing deleted, nothing reset.

== Q2: the retained fp-rollout-state.json neither permits nor refuses this signed set. It is WRITE-ONLY in this configuration. ==

crates/xtask/src/main.rs at 85f84d73 (xtask is byte-identical 53d625cd..85f84d73; the only files that changed are windows.rs and traceable-reqs.toml). state_path has EXACTLY TWO uses, and I enumerated them rather than sampling:
  :2424  READ -- reached only through version.unwrap_or_else(next_debug_version), i.e. ONLY when --version is absent.
  :2502  WRITE -- unconditional, after staging.
r5:871 passes --version 1 explicitly, so :2424 never runs and the retained file is never read. :2502 then writes {"version":1}, byte-identical to what is already on disk.

Measured on disk, read-only: .worktrees/304-w2-repr/target/fp-rollout-state.json is 13 bytes, content {"version":1}, mtime Sep 12 13:27. I did not touch it.

The record carries nothing else. write_debug_version (:2758) writes only {"version": n}; next_debug_version (:2741) reads only that one number. No artifact hash, no channel, no product version, no expiry, no subject sha.

=> No fresh attempt-specific path is REQUIRED by the contract. Keep the path as it is. If you want an attempt-specific path anyway it is harmless, but it should be a deliberate record-keeping choice and must NOT be presented as closing a version-collision risk, because it closes nothing.

== The collision this LOOKS like it carries is closed elsewhere, and I measured where ==

The real hazard behind your question is that a re-minted version 1 reads as already-applied and the host silently reuses the OLD exe edd3d8e0. It cannot happen here, for a reason that has nothing to do with the state file:
  debug_mark_applied (:2270-2295) writes the applied marker into <home>/releases via ReleaseCache.record_applied_state.
  r5:880 passes --home "$H" explicitly.
  $H is proven absent before the run: r5:732 DIES if the isolated home already exists (D10), mkdir at :829.
Fresh home => no inherited applied marker => version 1 cannot be mistaken for already-applied.

Two residuals I am naming rather than waving:
  1. debug_mark_applied's home falls back to spt_store::perch::spt_home() when --home is absent. r5 passes it. Any future edit that drops that flag writes the marker into the REAL LOCALAPPDATA spt-core home, not the isolated one.
  2. The state file lives inside the build pool $W/target/, which --build-current also writes into. Harmless while write-only, but a pool reap deletes it silently.

== DEFECT 1 in r5 (0891059048fd16e7...): line 979 greps a string the subject no longer prints ==

c_enf matches 'ActiveStore enforcement is'. At 85f84d73 that string occurs ZERO times in crates/ outside tests. The product now prints 'ActiveStore enforcement codes are' (windows.rs:826-828, the repaired arm). I checked all 13 other face strings individually: every one still resolves to at least one production site.

This is not a missing count, it is an INVERTED VERDICT. The enforcement face is the representation-accepted discriminator. An enforcement refusal is decide() returning Err, and it reaches stderr as LAN_FIREWALL_UNVERIFIED: <reason> because serveverb.rs:310-315 interpolates the reason into that line. With c_enf=0 the precedence ladder at r5:961-968 falls straight through to c_unver and records face=unverified-generic, whose own comment reads "decide() Ok(false): ABSENT or MISSPELLED" -- the exact opposite of what an enforcement Err proves, since reaching that arm proves pair_satisfied_by already matched. At exit 0, on the one outcome the repair exists to produce.

== DEFECT 2 in r5: 85f84d73 adds a refusal surface the driver does not count at all ==

ENFORCEMENT_REPRESENTATION_FAULT, 5 throw sites in the windows.rs query script, all in the production region below the test module. grep for REPRESENTATION_FAULT over r5 returns nothing. It also arrives as LAN_FIREWALL_UNVERIFIED: <reason>, so it also lands on unverified-generic. That collapses two of the four outcomes we agreed to keep separate -- "the host could not transport the codes" and "the codes were wrong" -- into one face, and both into a third thing neither of them is.

== Line anchors, re-derived independently ==

r5:99-101 already says the windows.rs line numbers do not hold. I measured the offsets rather than computing them: +73 for lines at or below 749, +75 for lines at or above 754, because decide()'s body gained two hunks. Spot-checked by content: snapshot 675->748, decide 713->786, the pair_satisfied_by call 724->797, reconcile 760->835, mismatch_message 817->892, cleanup 888->963.

== One pre-existing contract gap, NOT a regression from the repair ==

serveverb.rs is byte-identical between 53d625cd and 85f84d73. The contract block cites :379 as the LAN_FIREWALL_CLEAN site, but there are TWO print sites, :379 and :530, the second inside reconcile_lan_firewall. The driver's c_clean minus c_cleanunver subtraction is still arithmetically correct (one substring sibling), but a CLEAN counted in a trial cannot be attributed to the stop path on the count alone. Flagging it because it predates the subject move; it is not something r5 introduced.

Scope of everything above: source read of blobs at 85f84d73 and of the r5 file on disk, plus one read-only stat and cat of the state file. No cargo, no field run, no elevation, no host query, no write anywhere.