fix(#112): cross-type same-batch state conflicts — Family A + B

[vrkothekar]

Summary

Closes #112 (AG-7 follow-up). Fixes two families of cross-type same-batch state conflicts in _dedupCheck inside commit-handler.js, and wires up live-cluster integration tests.

• Family A (commit-handler.js): Five content-status tx types (CONTENT_DISPUTED, CONTENT_VERIFIED, CONTENT_RETRACTED, UPDATE_ORIGIN, PRESCAN_REVIEW_TRIGGERED) now reject a second same-batch tx for the same ctid even when the competing tx is a different type. Previously only same-type duplication was blocked; a CONTENT_DISPUTED + CONTENT_RETRACTED pair for the same ctid in one batch would both commit.
• Family B (commit-handler.js): Revocation-freeze extended to cross-type pairs — REVOKE_VP (or any revoke type) now blocks a same-batch UPDATE_PROFILE, KEY_ROTATED, etc. for the same tip_id via _actorTipId.
• Test harness (scripts/test-inbatch-dedup.js): 4 new cross-type Family A cases (dispute-verify, dispute-retract, dispute-update-origin, verify-retract) + 1 Family B case (revoke-update-profile). Fixed rejection-probe SQL to search tx_data column for ctid (cross-round rejection messages embed ctid in the full tx JSON, not in reason_detail). Changed FAILED→CROSS_ROUND timeout verdict for cross-type cases so the retry loop keeps running.
• Schema fix (validators/tx-validator.js): REVOKE_VP data schema listed reason_code and evidence_hash as required, contradicting _registry.js REVOKE_CONTRACT which marks them optional. Aligned with the canonical definition.

Implementation

commit-handler.js — Family A

Each of the 5 content-status mutator cases in _dedupCheck now looks for a sibling (any of the other 4 mutator types) already validated for the same ctid:

const sibling = validated.find(t =>
  CONTENT_STATUS_MUTATORS.includes(t.tx_type) && t.tx_type !== TX_TYPES.CONTENT_DISPUTED && t.data?.ctid === d.ctid);
if (sibling) return { valid: false, error: `content-status conflict in batch: ${sibling.tx_type} already accepted for ${d.ctid}` };

CONTENT_STATUS_MUTATORS is a module-level frozen array to keep the guard DRY across all 5 cases.

commit-handler.js — Family B

REVOKE_TYPES (already module-level) used with new _actorTipId(tx) helper to extract the acting identity's tip_id across 17 tx types. Freeze guard: if any revoke type is already validated for the same tip_id, subsequent state-changing txs (UPDATE_PROFILE, KEY_ROTATED, etc.) are rejected.

Scope

• Cross-round gap (canDispute/canRetract not blocking VERIFIED status) is out of scope — pre-existing behavior separate from Cross-type same-batch state conflict: dedup is per-type, stateful checks blind to siblings (AG-7/#87 follow-up) #112.
• revoke-update-profile test shows CROSS_ROUND ◐ (not IN_BATCH) because REVOKE_VP and UPDATE_PROFILE frequently land in different consensus rounds. The in-batch path IS implemented; the test confirms no FAILED (dedup miss) result.

Test plan

• Live-cluster regression: node scripts/test-inbatch-dedup.js --case all --attempts 5
  • Expected: dispute, verify, update-origin, retract, key-rotate, dispute-verify, dispute-retract, dispute-update-origin, verify-retract → IN_BATCH ✅
  • Expected: revoke-update-profile → CROSS_ROUND ◐ (acceptable — no FAILED)
• Regression run result (this PR): all 9 content-status cases IN_BATCH ✅, revoke-update-profile CROSS_ROUND ◐, cluster stayed up (round ~700 at end of run)