bug: automatic sandbox reconnect replays retained output #3647

User Story

As a developer attached to a long-running sandbox, I want transport recovery to resume from the output I last received, so that a brief interruption does not flood my terminal with duplicate history.

Problem Statement

Each canonical-main SSH attachment subscribes at the oldest event still held in the supervisor output buffer. PR #3573 adds automatic SSH reattachment after transport loss, so every recovery attempt can replay up to 1 MiB of already displayed output. Multiple attempts on a flaky connection repeat that history each time.

Impact / Why This Matters

Duplicate output obscures the point where the interruption occurred, fills terminal scrollback, and makes logs appear to contain events that happened more than once. Manually finding the new-output boundary is unreliable, especially for verbose workloads. Disabling recovery avoids duplication but gives up transparent sleep and wake recovery.

Acceptance Criteria

• An automatic reconnect resumes after the last output successfully delivered to that logical attachment.
• Output produced while transport is unavailable is delivered after recovery when it remains retained.
• Repeated recovery attempts do not duplicate output already delivered before an earlier attempt.
• Manual fresh attachments retain the documented recent-output replay behavior.
• Tests cover output before, during, and after at least two transport recovery attempts.

Reproduction Steps

1. Create a persistent sandbox whose canonical main process emits enough output to populate retained history.
2. Run openshell sandbox connect and observe the output.
3. Interrupt the established SSH transport so automatic recovery starts.
4. Observe that the replacement attachment replays retained output that the terminal already displayed.
5. Repeat the interruption and observe the same history again.

Environment

• OpenShell: PR fix(sandbox): preserve local sessions across host sleep #3573
• OS: any supported client OS
• Runtime, deployment, or integration: any gateway with canonical-main SSH recovery

Context

Follow-up to #3573 and #3638. A complete solution likely needs a logical attachment cursor or equivalent resume position rather than changing fresh-attachment replay semantics.