feat(conformance): add the ${CONTAINER_ID} argv token and retire two parity carriers

[pofallon]

Deletes parity_exec and parity_up_exec. Both were held by records that turned out to be answerable rather than pending.

res-exec-per-side-argv was obsolete, not outstanding

It claimed a declarative operation needed per-side argument vectors, because deacon took --env where the reference takes --remote-env. But cli.rs:534 already declares:

#[arg(long = "remote-env", action = clap::ArgAction::Append, alias = "env")]

--remote-env is the primary flag; --env is a hidden legacy alias. So one shared argv runs on both CLIs and the comparison is a true differential. case-exec-decl-env-propagation landed and the residual is deleted.

Per-side argv was deliberately not built: it would let a case compare two different commands and call the result parity.

${CONTAINER_ID}, for the behavior that genuinely had no evidence

parity_up_exec was the sole evidence for bhv-exec-container-id-metadata (T110), which needs a case able to address the container a previous operation created. runner::substitute_argv now resolves ${CONTAINER_ID} to the most recent successful up/exec op's container — the op loop already tracked it, so threading it in was the whole change.

Per the design commitments:

• No new Operation field. It is a string inside the existing argv, so the operation model is unchanged and every existing caseHash is byte-identical — no snapshot needed re-recording.
• Fails loud when the token appears with no preceding successful up, matching the ${WORKSPACE}-without-a-fixture discipline. Handing the literal ${CONTAINER_ID} to the CLI would make the op fail for an unrelated reason and read as a real divergence.

case-exec-decl-container-id-metadata runs up, then exec --container-id ${CONTAINER_ID} printing $REMOTE_ONLY — a value the fixture declares in devcontainer.json and nowhere else, so a byte-identical result on both sides proves each CLI recovered it from the label it stamped rather than from a workspace it re-read.

Both new cases verified agree on the live differential against pinned oracle 0.87.0.

equivalence-report --carrier is now repeatable

Deleting two carriers in one change needs both judged in one ledger, because the ledger file is rewritten per run — and judging every carrier instead drags in ones legitimately red for unrelated reasons, which can never clear anything.

A --carrier naming a non-carrier is now a fail-loud error rather than an empty result. Otherwise a deletion could be authorized by a ledger that never looked at the carrier it was authorizing.

Ledger: 5 units, all equivalent. migration report --ledger then listed both in deletableCarriers.

Three guards fired, and were obeyed rather than loosened

Guard	What happened
the_surviving_set_is_mutually_consistent	count 6 → 4; documented to drop as carriers retire, lowered to the actual set with the reason recorded
no_parity_source_uses_ignore_or_legacy_skip_idioms	file floor 9 → 7; same, and it is explicitly "not a coverage claim"
check_nextest_profiles_flags_leaked_live_binary	the interesting one — it probed with the literal name parity_exec. Retiring that carrier would have made the guard pass by selecting a binary that no longer exists, so it would have stopped detecting leaks silently. The probe name is now derived from the registry, so the guard cannot outlive its subject.

Deletion completeness

crates/deacon/tests/parity_{exec,up_exec}.rs deleted, plus: .config/nextest.toml (all filters), fixtures/parity-corpus/registry.json, the case-exec-parity / case-up-exec-parity legacy pointers, mapping.json, residuals.json, CLAUDE.md, and the T107/T110 deferral entries. conformance/migration/baseline.json is deliberately untouched — it is retained as evidence, never rewritten, and its V25 drift gate was retired in T099 for exactly this reason.

Verification

Gate	Result
cargo fmt --all -- --check	pass
cargo clippy --all-targets --all-features -- -D warnings	pass (0)
cargo nextest run --profile dev-fast --no-fail-fast	3588 passed
validate / certify	pass; 0 blocking
migration check	118 units — migrated 75, residual 43, unaccounted 0; 0 violations
snapshot check	1 fresh, 0 stale
parity_registry_check	10/10 pass
cargo nextest run --profile parity -E 'binary(=parity_conformance_runner)'	both new exec cases agree

The three case-state-* cases diverge on this branch because it is cut from main, which does not carry the T115 metadata fix (#365) — they agree once that lands. The 51 chan-structured-output T113 cases remain red as documented.

🤖 Generated with Claude Code

https://claude.ai/code/session_017UCGzJEFZd85HJqz1Wx2kE