547 specs carry TWO seals, and `seal --save` writes only one of them

[gHashTag]

Found while repairing compiler/codegen/testgen.t27 on #2766.

seals in .trinity/seals            1316
specs sealed TWICE                 547   (module-name key AND path-derived key)
pairs that already DISAGREE         31

Examples of the pairing: ast.json / compiler_ast.json, testgen.json / codegen_testgen.json, gwt_model.json / brain_gwt_model.json.

t27c seal <spec> --save writes to .trinity/seals/<module>.json where the name is now path-derived, so it updates exactly one file of each pair. The other keeps whatever it held — and the gate reads both. On this branch that produced a repair that fixed the spec, re-sealed it, and still failed coverage on the twin.

Thirty-one pairs disagree today. Each one is a spec where the record says two different things about the same four outputs, and either answer can be the one a reader believes.

What is NOT the fix

Deleting the twins wholesale. Some of the 547 may be the only seal a downstream reader knows by name, and a seal that vanishes is indistinguishable from a spec that was never sealed.

What would be

Either seal --save updates every seal whose spec_path matches, or the gate refuses a spec that has more than one seal — one truth per spec, chosen deliberately, with the 31 disagreements resolved by re-sealing rather than by picking.

Refs #2754

[gHashTag]

Correction to the count above

I wrote "Thirty-one pairs disagree today. Each one is a spec where the record says two different things about the same four outputs." That is wrong on the second sentence, and the error is mine.

tri seals sync-twins recomputes each twinned spec's seal with t27c seal rather than picking a side, and it refused all 31:

  unread  specs/brain/gwt_model.t27  -- `t27c seal` did not produce five hashes

$ t27c seal specs/brain/gwt_model.t27
Error: No such file or directory (os error 2)

All 31 name a spec file that is not in the tree. They are pairs of dangling seals — the seal gate's own category, 89 of them in seal_baseline.txt. Neither answer can be checked, because the file both describe cannot be fetched. That is a different, smaller problem than two live contradictions about a spec someone might read.

What stands from the original report:

• 547 specs carry two seals; --save writes one of them
• the drift is real and it bites: on #2769 a codegen change drifted 228 seals, 125 re-seals fixed 125, and 103 twins stayed red until they were synced
• the decision — one seal per spec, or a save that writes every match — is still open

What does not stand: the claim that 31 live specs currently have contradictory records. Zero do.

tri seals sync-twins (merged on #2769) closes the operational half: after any codegen change, re-seal, then sync. It recomputes rather than guesses, and refuses a spec whose current generation is none — the anti-pattern one commit on #2766 committed.