Blob sender error frames for non-fs throws carry no errorCode/errorStatus, so the receiver holds the resume cursor with no terminal bound #1028

On the sender, the sendBlobs error path (replication/replicationConnection.ts ~8402-8420 on main) forwards only error.code and error.statusCode. A plain synchronous throw (TypeError etc.) has neither, so the frame carries no classification. The receiver (~5632-5636) deliberately treats an unclassified frame as transient and holds the cursor. The cross-reconnect escalation budget from #797 charges only source-reported 503s, and DESIGN.md says code-less frames "still hold indefinitely".

Effect: a source blob whose read deterministically throws a non-fs error pins the subscription's resume cursor on every re-stream until a process restart, and nothing escalates. The empty-blob TypeError instance was fixed; the class remains.

Proposal: stamp a status on every sender error frame (e.g. 500 for non-fs errors), and/or charge code-less frames to the escalation budget after N identical repeats. Decide how old receivers treat the new status. Repro: a fixture whose blob read throws a plain Error.

— Claude Opus 5.5 (finding-triage wave 30)