fix(coding-agent): finish mixed-version snapshot catch-up isolation #21

Problem

PR #14 closed #11 with immutable snapshot transfer and authoritative cleanup, but follow-up mixed-version and large-transcript validation found remaining catch-up hazards:

• the fresh snapshot-generation nonce is not capability/schema-gated for stock v0.8.1 peers;
• a malformed, incomplete, or changing generation can still escape its attachment boundary or recycle healthy worker state;
• large snapshot preparation, private framing, drain waits, and spill ownership need tighter generation fencing and bounds.

This issue tracks that follow-up separately so #11/#14 remain the record of the shipped foundation.

Required outcome

• Negotiate a frozen fresh-generation capability without changing daemon protocol 7.
• Use a distinct schema revision and identity for the new wire shape.
• Validate begin/chunk/end identity and monotonic progress before publication.
• Permit at most one bounded fresh-generation retry for the affected attachment without closing or self-requeueing an otherwise healthy worker.
• Fence retries, aliases, attachments, and late frames by the exact attachment epoch.
• Bound preparation, framing, backpressure, spill retention, and cleanup while preserving mixed current/stock v0.8.1 compatibility.
• Record the fork/upstream-overlap decision in .pylon/features.yaml and .pylon/upstream-review.md.

Coordination

• Fork tracker: Track Pylon fork parity and upstream overlap #1
• Shipped foundation: fix(coding-agent): keep snapshot catch-up failures isolated #11 and PR fix(coding-agent): keep snapshot and recovery failures isolated #14
• Pylon provider tracker: Prime provider parity: tasks, automation, and upstream watch pylon#114
• Candidate PR: fix(coding-agent): isolate snapshot catch-up failures #19

This is Pylon/Prime reliability work. It has no Comet dependency or consumer requirement.

Claimed implementation

• branch: fix/snapshot-recovery-integrity
• worktree: /Users/rynfar/.prime/worktrees/prime-snapshot-recovery-integrity
• base: pylon@91e13b6798343995291ccca6f523fba81ff96cd6
• source candidate: 8b504e3774875c241c5d0d3b4b588a09f4aa3f8e
• current exact candidate: 0759797188abc22d0cc9dec967218db0a3c161fb

The PR must receive updated ledger entries, exact-head validation, recorded maintainer approval, and green hosted checks before merge.