feat(verdict): write-expiry groundwork — expired taxonomy, contract docs, upstream ask

[FelineStateMachine]

Part of #12. Closes #14.

Server-enforced write expiry needs a surface that does not exist at the pinned alpha — verified from source: at the jazz alpha.53 publish commit, the SealedBatchSubmission envelope is {batch_id, mode, target_branch_name, batch_digest, members, captured_frontier} with no expiry or deadline field anywhere in the submission path, and the only expired the codebase knows is the transport's unauthenticated-response code for rejected JWTs. The batch-fate code space at the pin is four codes — permission_denied, transaction_conflict, permissions_head_missing, invalid_batch_submission — an open string on BatchFate::Rejected, not a closed enum. This PR lands everything that is safe and useful ahead of enforcement:

• Taxonomy: the registry now classifies the full observed code space. transaction_conflict and permissions_head_missing are registered permanent, each pinned by a harness test that provokes it end to end (tests/write_conflict_test.ts): a losing concurrent transaction is final, deterministic across reconnects, batch-correlated, and never rebased; a store deployed without a permissions head fails closed on both verdict surfaces, and publishing permissions later does not revisit the fate. invalid_batch_submission stays unregistered (transient by default): every trigger is an envelope invariant the client runtime computes itself, and the one author-reachable shape — committing an empty transaction — throws synchronously before any batch exists, so no rejection carrying it can be observed from the public API; the registry doc comment records this. expired remains registered permanent and inert until a store emits it.
• Docs: the write-verdicts page carries the four-code taxonomy table, records the re-derivability boundary at the pin (a transactional batch committed offline is never re-adjudicated; waiting on it fails with a runtime error, not a verdict), and states the expiry contract — client-asserted deadline declared outside the payload, arrival-time enforcement with a two-minute skew tolerance, honest-client threat model, and the expiresAt + 2 × tolerance soundness rule — mechanism-neutral: it binds whichever component enforces it. The page states plainly that nothing enforces it at the pinned alpha and that the enforcement design is in progress at the node layer.
• Design record: docs/upstream-write-expiry.md is the reference spec for the vendor surface lofi would prefer if jazz offered it (recorded as upstream(jazz): expiresAt on the sync envelope with an engine-enforced expired verdict lofi#145; upstream wishes are labeled reference issues, nothing is filed). Its wire sketch is source-accurate: expires_at covered by a v2 digest manifest, the rejection code needing no wire change, captured_frontier compatibility-only.

Evidence grading. Every load-bearing claim here is source-verified (jazz repo at the alpha.53 publish commit, cross-checked against the pinned binaries by hash) or behaviorally observed in the harness; nothing rests on binary string inference. Where the two prior audits of the code space disagreed (one code vs three), both were artifacts of their method — a JS-artifact grep and an under-specified strings pattern; source enumeration settles it at four.

Checklist items of #12 that remain blocked on enforcement and keep the issue open:

• Landing an enforcement surface (gate-level at the node — under evaluation on feat: server-enforced write expiry — expiresAt in the sync envelope #12 with the frame-parseability grading now recorded there — or engine-side per upstream(jazz): expiresAt on the sync envelope with an engine-enforced expired verdict lofi#145).
• Harness coverage mirroring tests/write_verdict_test.ts for expired (late write rejected, batch-id correlation, determinism across reconnects) — impossible until something can reject a late write.

deno task check clean; deno task test 64/64; deno task publish:dry succeeds.