Three seals from #6789 carry absolute agent-worktree spec_path -- devhome scan + seal coverage red on master #6849

Second master-wide red from #6789: three seals carry an absolute agent-worktree path.

The devhome gate (secret-scan, "Block hardcoded /Users/playra/ paths") fails on pure master with:

.trinity/seals/theory_CompilerTheoryIsaRoundTrip.json:11:  "spec_path": "/Users/playra/t27/.claude/worktrees/agent-a008408b9580a5586/specs/compiler/theory/isa_round_trip.t27",

Three seal files minted in #6789's agent worktree commit spec_path with the full absolute path: isa_T27a.json, isa_Tri27Encoding.json, theory_CompilerTheoryIsaRoundTrip.json. Two gates read them:

• devhome scan: the literal /Users/playra/ fails the grep allowlist (this is exactly the fix class the workflow's own comment describes: "seal spec_path fields the seal gate RESOLVES ... were fixed" -- made repository-relative).
• seal coverage (root / spec_path in tools/check_seal_coverage.py): an absolute path that exists on no runner classifies the seal as phantom (the path appears in no commit), so the three seals read as broken on every CI machine.

Fix: rewrite the three spec_path values to repository-relative (specs/isa/t27a.t27, specs/isa/ternary_encoding.t27, specs/compiler/theory/isa_round_trip.t27). Verified before committing: each relative path exists on master and its sha256 equals the seal's recorded spec_hash, so every other claim in the seal (spec_hash, the four gen_hash_*) is unchanged and stays valid -- only the location field was machine-specific.

Seals should not be minted from worktrees with absolute paths; the durable version of that rule belongs to the seal tool (sealing relative to repo root), not to this repair.