send_to retryable receipts never terminalize: a target stuck booting yields a queue a lead can wait on forever

[EtanHey]

Follow-up from the review of #466 (lane F1), raised by the reviewer as recommended, not blocking.

What

send_to now converts a RetryableDeliveryError from the interactive gate into a nonterminal queued receipt instead of a terminal failed one (#466). That is correct for the lane's charter — a retryable refusal is not a terminal outcome, and flattening it was the fleet's #1 receipt lie.

But the queued receipt has no deadline:

• queueDelivery sets verify_deadline_at: null (src/agent-engine.ts:6657+)
• the drain loop backs off to a 30 s cap and retries forever (src/agent-engine.ts:7121-7130)
• it only fails if the agent record disappears entirely (src/agent-engine.ts:7050)

So a target stuck booting (or otherwise never reaching an interactive state) produces a receipt a lead can wait on indefinitely.

Why it is not urgent

• The genuinely-dead cases still terminalize: assertAgentRouteHasTui throws a non-retryable error for a bare-shell pane, and that path is unchanged.
• The gate at src/server.ts:10998 is the only RetryableDeliveryError throw site in the server, and it fires before any text is typed, so requeueing carries no double-type risk.

Suggested fix

Give the retryable-requeue path a bounded lifetime — either a verify_deadline_at on requeue, or a max retry count after which the receipt resolves failed_confirmed with the accumulated gate reason. Either way the lead gets an answer rather than an open queue.