[tnunamak]

When the streaming browser view closes or reconnects, BrowserSurface unmounts the Remote Surface viewer but leaves its PDPP transport live. A late keystroke, viewport update, selection read or clipboard write then POSTs to the old stream's endpoints, and late replies still reach subscribers. A paste whose clipboard read finishes after a reconnect can reach the replacement stream through the shared endpoint refs.

This adds dispose() to createPdppRemoteSurfaceTransport (stream-viewer-remote-surface-transport.ts). After it runs, the transport is inert and idempotent:

• send, subscribe, receiveSseMessage and setPresentationAttachmentReady do nothing, and emit drops replies already in flight.
• The host logger is never called again. That logger batches events into POST /api/stream-debug, so a request failing after disposal would otherwise use the network. Late rejections and non-2xx replies for input and clipboard are dropped before they are logged.
• sendClipboardText returns false, including for a request that was already sent when disposal happened.
• The queued viewport and subscribers are cleared.

The viewer mount and cleanup moved from the BrowserSurface effect into mountBrowserSurfaceViewer (stream-viewer-browser-surface-lifecycle.ts). The page still builds the viewer, so its configuration is unchanged. Cleanup unmounts the viewer and then disposes the transport in a nested finally, so a throwing mount notification or a throwing viewer.unmount() still retires the transport. Failed initialization and normal cleanup share one idempotent release. Diagnostics logging cannot throw out of the mount or skip release, and a throwing transport notification no longer skips the viewer notification.

The mount does not write presentation-attachment readiness: the stream owns that fact (the page sets it as the SSE attachment comes and goes) and every transport only reads it. Before, cleanup wrote false, so replacing a viewer (for example on a seed-viewport size change, which remounts BrowserSurface without a new attachment) left the replacement queueing every viewport. A mount rejection now registers its handler right after mount() and is not logged once the mount is retired.

Not changed: requests already on the wire cannot be recalled; only their effects on the viewer are dropped. The /input schema is untouched (that is #338).

Tests: stream-viewer-remote-surface-transport.test.ts (14) and stream-viewer-browser-surface-lifecycle.test.ts (14). The lifecycle tests mount the real mountBrowserSurfaceViewer from a React component under jsdom: StrictMode mount, cleanup and remount; a fast remount that must not dispose the new mount's transport; a stale cleanup that must not clear the newer mount; a throwing notification or unmount; the readiness ref shared across sequential and overlapping mounts, asserting the replacement's viewport POST and ack; a mount rejection after cleanup with a recording host logger; a throwing notification during initialization with a pending mount rejection; and a throwing host logger on the initialization-failure and live-rejection paths. They do not mount BrowserSurface itself: it is a private component inside a 6,000-line file that pulls in CSS and the whole stream page, so the tests drive the extracted function through the same useEffect shape.

Against the previous head (5e76f48), 4 of the new tests fail: rejected input fetch after dispose, late non-2xx input after dispose, clipboard failure after dispose (each posts to /api/stream-debug), and a throwing notification skipping unmount and dispose. The remaining new tests are regression guards that pass on both. The 5 new readiness, late-rejection and initialization-failure tests fail against the earlier head (9ccd782) and pass now. All 14 lifecycle tests pass; the 3 added in the last commit fail against 25b55c7. The other stream-directory tests are unaffected by that commit (293 passed in the full-directory run before it); npm run types:check in apps/console passes. ultracite check shows the same findings on stream-viewer.tsx as main, minus one useExhaustiveDependencies (the extracted effect).

stream-viewer.tsx is also edited by #620 (connector icons) at other lines (1577-1661, ~5954, ~6001); the hunks are disjoint.

Assisted-by: AI