Pending queue: resume inactive sessions with new input after machine reconnect

[karolzlot]

Problem statement

When a new user message is durably queued for an inactive, vendor-resumable session while its owning daemon cannot start a consumer, the message can remain queued after the machine reconnects until the user revisits the session and retries resume manually. A transient daemon or machine restart can therefore leave a conversation stalled indefinitely even though both the input and resume identity are intact.

Proposed solution

Treat newly queued input for an inactive resumable session as a durable request to ensure a consumer, rather than a one-shot client action. When the owning machine becomes reachable, re-evaluate the existing resume eligibility and use the existing resume path with bounded retries until the session becomes serviceable, the input stops being eligible, or a terminal resume result is available.

Acceptance criteria

• A new unblocked user message created after an unarchived, vendor-resumable session became inactive is processed when its owning machine becomes reachable, without another message or a manual resume.
• The pending-consumer intent survives client closure and normal daemon or machine reconnects.
• Retries are idempotent and cannot create duplicate runners or deliver the same queued input twice.
• Retries use bounded backoff and expose a terminal failure while preserving the existing manual retry path.
• Happier does not auto-resume when the input is blocked, cancelled, already claimed, or otherwise unsafe to deliver, or when the session is archived, not resumable, already has a serviceable consumer, or has user action that must be resolved first.
• Existing delivery behavior for active sessions remains unchanged.

Non-goals (optional)

• Automatically reviving a session solely because it has historical pending rows from before its current inactive interval.
• Replacing the Pending queue or provider resume mechanisms.

Priority (optional)

P2

Additional context (optional)

• The current resume guide says that sending to an inactive, resumable session while its machine is reachable resumes the session first: session-resume.mdx.
• On public dev at bd09e88, the Pending submit path persists the row and makes one ensureSessionRuntimeForPendingInput call, then returns wake_failed when that call fails: submitSessionUserMessage.ts. The UI tests cover the resulting warning and a user-initiated retry, but no retry on machine reconnect: SessionView.sendMessage.resumeInactive.pendingQueue.test.tsx, manual retry test.
• Related: #134 added durable queuing for inactive sessions and describes delivery once the session reconnects. This request covers retaining and retrying the consumer-start intent when the initial resume attempt cannot reach the daemon.
• Searches across open and closed issues for inactive-session resume, queued input, daemon reconnect, and pending consumer retry found no report of this exact gap. #213 and #316 concern sessions that remain active with a live or registered runner path; this request concerns an inactive session with no consumer.