mecatui: add Recover and continue to the sessions menu

Problem

A main session left with a persisted running state after a computer crash cannot be continued from /sessions: the browser classifies it as active elsewhere and permits only inspection. Recovery exists through exact-ID startup resume, but that workaround is not discoverable in the browser.

Confirmed operator experience

1. The computer crashed during a session in the ToolHive workspace.
2. After restarting, /sessions showed a running triangle for that session and only allowed read-only inspection.
3. The operator copied the exact ID and used mecatui --resume <exact-session-id>.
4. The operator confirmed they were able to continue the session.

The crash and successful workaround were reported by the operator. We have not captured a live ownership trace or independently inspected that session's storage. This issue concerns exposing the working recovery path, not asserting that every persisted running session is orphaned.

Expected behavior

Offer Recover and continue from the sessions menu for an interrupted or potentially orphaned main session. The action asks the server to establish whether recovery is allowed and continues through the existing guarded run-admission machinery, rather than requiring a CLI restart or blindly changing persisted state.

Acceptance criteria

• An operator can invoke a discoverable, keyboard-accessible Recover and continue action from /sessions without restarting mecatui or manually editing storage.
• The server rechecks authorization, session kind, exact placement, local liveness, and applicable lease/ownership safeguards at execution time. A stale inventory response is never authority to recover.
• A genuinely active session cannot be taken over by this action. Unknown ownership or unavailable placement produces an actionable, honest explanation and leaves the session unchanged.
• Use the existing main-session recovery/run-entry path rather than a client-side state reset or duplicate history-repair implementation. Define behavior for lease-less deployments explicitly; do not claim cross-process exclusivity from a process-local liveness check.
• Successful recovery preserves conversation history and repairs interrupted tool-call pairing using existing semantics. It does not blindly replay side-effecting tools; explain that a tool may already have changed external state before the crash.
• The UI clearly distinguishes loading the recovered conversation from submitting the next prompt. Recovery failure does not rebind the client to an unusable session or discard its current chat/draft.
• Preserve the separate awaiting-approval workflow; do not abandon pending approvals or expose child/scheduled sessions as recoverable public chats.
• Offline coverage exercises the browser-to-server path for crash-orphan recovery, genuinely live refusal, ownership changing after inventory listing, placement/ownership failures, and preserved history/tool pairing.
• Document the menu workflow and retain exact-ID --resume as a supported alternative.

Existing implementation context

• internal/adapter/server/service.go:8040-8045: persisted running sessions have continuation disabled as active elsewhere.
• cmd/mecatui/startup_resume.go:95-144: exact-ID startup continuation allows loading a running main-session transcript; latest selection remains conservative.
• internal/adapter/server/service.go:4501-4681: guarded run admission and running-state recovery.
• internal/adapter/server/service.go:6950-7038: automatic staleness reconciliation has a 30-minute age gate plus liveness and optional lease checks. Waiting for that sweep should not be the only browser experience.

Line references describe the source inspected when filing and may move. The existing implementation also documents limitations without fenced writes; reuse is not permission to overstate its guarantees.

Scope and relationships

This issue owns the recovery action. Explicit session-state/liveness presentation is a separate UX issue; read-only transcript copying is #1620. Broader cross-process fencing and automatic replay of external operations are not implied by this request.

Start with the sessions handling in internal/adapter/server/service.go:8040-8045 and guarded run admission in service.go:4501-4681; compare these with cmd/mecatui/startup_resume.go:95-144. Trace the browser-to-server sessions action and existing recovery semantics before changing behavior. Done means a discoverable, guarded recovery flow preserves history and tool pairing, refuses unsafe recovery, keeps approvals separate, and has offline coverage plus documentation.