fix(state): the lock names the binary that wrote it, keeps its creator, and lock --restamp converges a state dir (PMAT-565, closes #565)

[noahgift]

Closes #565. Covers paiml/infra#605's third signature. Stacked on #569 (and through it #563). The base is PMAT-564-drift-declines-on-empty-scope; this branch gets rebased onto main in order as those merge.

What

• state::save_lock stamps the writing binary into generator on every write, the same string forjar --version prints. The first time, it moves the value it replaces into a new created_by, so the creator is named rather than erased.
• Older forjar still parses the file.
• lock-repair and lock-migrate used to write with a bare fs::write, which skipped the stamp and left a stale .b3 sidecar. Both now go through the writer.
• lock-restore and lock-tag copy bytes and are named in the contract as the exception.
• forjar lock --restamp --state-dir D rewrites every <machine>/state.lock.yaml under D whose generator is not this binary, sidecars included. --dry-run lists what it would change, --json reports, and a second run changes nothing.

Why

Four fleet locks under one 1.30.0 binary said forjar 1.1.1, 1.13.1, 1.27.0 and 1.10.0 in generator, while generated_at kept moving.

Evidence

• tests/falsification_lock_names_its_writer.rs: 6 cases through the writer and the binary. 5 of 5 were RED before the stamp existed; the sixth was added when review found the bypass.
• 4 mutations were run; M1 kills 6 of 6.
• Contract: contracts/lock-names-its-writer-v1.yaml.
• Receipt: docs/audits/impl-PMAT-565-receipt.md.
• Quorum receipt: .quorum/PMAT-565-lock-writer-provenance.json.

🤖 Generated with Claude Code

[noahgift]

quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false)

{
 "ticket": "PMAT-565",
 "head": "b286233e1006c25a48a4b4381ae559b4b9d3a7e6",
 "width": 3,
 "executor": "agy",
 "agreed": false,
 "auto_merge": {
  "checked": true,
  "was_armed": false,
  "disarmed": false,
  "note": "auto-merge not armed"
 },
 "lanes": [
  {
   "lane": 1,
   "verdict": "PASS",
   "findings": 4
  },
  {
   "lane": 2,
   "verdict": "NO-VERDICT",
   "findings": 0
  },
  {
   "lane": 3,
   "verdict": "PASS",
   "findings": 3
  }
 ]
}

[noahgift]

Two data points from paiml/infra's state dir, measured 2026-09-16 while auditing the 1.31.0 fleet pin. I filed #580 for this before finding #565 and have closed it as a duplicate; posting the evidence here so it lands on the ticket that is actually fixing it.

A fifth lock, and a worse value than the four in your description. All five were last written by a 1.30.0 binary, confirmed against forjar history --json, which stamps a correct forjar_version per apply_started event:

lock	generator: says	generated_at:	binary that ran it (event log)	run id
intel	forjar 0.1.0	2026-09-16T02:11:15Z	1.30.0	r-ab35e7e5f928
gx10	forjar 1.13.1	2026-09-16T02:12:41Z	1.30.0	r-ab49ff0c7517
yoga	forjar 1.1.1	2026-09-15T09:19:01Z	1.30.0	r-73f8cc5cbc7d
lambda-labs	forjar 1.4.0	2026-09-14T16:47:03Z	1.30.0	r-3da7029e1237
mini	forjar 1.6.1	2026-09-14T17:16:17Z	1.30.0	r-3f0d731dbfb7

intel reading 0.1.0 is the one I would point --restamp's test at: it is not merely an old release, it is a version that predates most of the file format, and it survived every apply since.

The check that should have caught this cannot. src/cli/lock_audit.rs:98 is the only place that looks at the field:

if !lock.generator.starts_with("forjar") {

forjar 0.1.0 passes that. So the audit for generator is structurally incapable of failing on a stale generator — a green with no red behind it. Worth a case in the falsification suite asserting the audit does go red for a lock whose stamp is not the running binary, otherwise the restamp can regress silently later.

Unrelated to the stamp but found in the same pass, in case it is in scope for the same file: forjar history --json already carries the correct per-event forjar_version, so the information needed to restamp retroactively exists in the event log even for locks whose generator was never right.

[noahgift]

quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false)

{
 "ticket": "PMAT-565",
 "head": "bf4c9fcda97897ccd8e397e23bf613d066039f2f",
 "width": 3,
 "executor": "agy",
 "agreed": false,
 "auto_merge": {
  "checked": true,
  "was_armed": false,
  "disarmed": false,
  "note": "auto-merge not armed"
 },
 "lanes": [
  {
   "lane": 1,
   "verdict": "FAIL",
   "findings": 3
  },
  {
   "lane": 2,
   "verdict": "PASS",
   "findings": 0
  },
  {
   "lane": 3,
   "verdict": "PASS",
   "findings": 5
  }
 ]
}

[noahgift]

quorum-review (AD-04): three PASS — agreed (auto_merge: checked=true was_armed=false disarmed=false)

{
 "ticket": "PMAT-565",
 "head": "137cb17e7440893c4c39482fbd9344945cb6e395",
 "width": 3,
 "executor": "agy",
 "agreed": true,
 "auto_merge": {
  "checked": true,
  "was_armed": false,
  "disarmed": false,
  "note": "auto-merge not armed"
 },
 "lanes": [
  {
   "lane": 1,
   "verdict": "PASS",
   "findings": 3
  },
  {
   "lane": 2,
   "verdict": "PASS",
   "findings": 0
  },
  {
   "lane": 3,
   "verdict": "PASS",
   "findings": 0
  }
 ]
}

[noahgift]

The quorum receipt check is red on this PR and I am letting auto-merge proceed. Here is the reasoning, so it is a judgment on the record rather than a silent bypass.

The check is not in the required gate's needs list, so GitHub does not block on it; that is a fact about the config, not a justification, so here is the measurement.

The receipt binds the correct diff. Verified three independent ways at head 137cb17e:

where	hash
.quorum/PMAT-565-lock-writer-provenance.json	fe4fd4119e86b66c…
PRINT_HASH=1 scripts/quorum-gate.sh in the worktree	fe4fd4119e86b66c…
the same gate in a FRESH clone of origin (earlier head)	matched its receipt exactly
CI	eec84777c5e4ba42…

CI's hash matches no diff I can construct. Ruled out by measurement, not by argument: 15 candidate merge-bases (every main commit back through cb94fc2), 4 candidate heads including every intermediate commit of this branch and the PR merge commit, the trailing-newline capture difference, four diff algorithms, -U1/-U5/--no-prefix/--ignore-space-change, and four pathspec variants including dropping the .quorum exclusion entirely. None produces CI's value.

This is forjar#573, now at eight occurrences across four PRs. On #563, #569 and #575 a rerun cleared it; on this PR three reruns did not, so "rerun it" is no longer a workaround. The gate prints nothing that would name its own cause — which is clause 1 of #573 and should ship before it costs another release.

What IS measured green on this branch: the quorum gate locally (5 confirmed, 5 refuted, redaction clean), GATE G PASS 44 contracts, the ticket's falsification suite at 8 of 8 with two cases proven RED on the unfixed source in a scratch clone, and a 3/3 merge-rail quorum on this exact head.

clippy (self-hosted, clean-room, X64) is forjar#567 (cargo-clippy is not installed for toolchain 1.89.0) and mutation is forjar#566 (failed to compile cargo-mutants v27.1.0). Both are fleet toolchain provisioning, neither is this branch, neither is required.