chore(terminal): tighten the stale-stream comments

src/renderer/src/components/terminal-pane/remote-runtime-pty-transport.ts

@@ -379,7 +379,7 @@ export function createRemoteRuntimePtyTransport(
       pendingClaimQueryReplyCount += 1
     }
   }
-  // Why: the claim is only "resolved" once its queued input actually reaches a stream; clearing the flag alone strands those bytes (STA-5098).
+  // Why: clearing the claim flag without draining strands the queued bytes.
   const flushPendingClaimInput = (stream: RemoteRuntimeMultiplexedTerminal): void => {
     const queued = pendingClaimInput
     pendingViewportClaim = false
@@ -1976,7 +1976,7 @@ export function createRemoteRuntimePtyTransport(
     ) {
       nextStream.resize(desiredViewport.cols, desiredViewport.rows)
     }
-    // Why: drain on every install, not just a still-pending claim — a live claim may have cleared the flag first (STA-5098).
+    // Why: a live claim may already have cleared the flag, so drain on every install.
     flushPendingClaimInput(nextStream)
   }
 

src/renderer/src/runtime/remote-runtime-terminal-multiplexer.ts

@@ -1185,8 +1185,7 @@ class RemoteRuntimeTerminalMultiplexer {
     )
   }
 
-  // Why: sendFrame only gates on socket readiness, so a handle whose stream was dropped (close or
-  // reconnect) would report success while the host drops the unknown stream id (STA-5098).
+  // Why: sendFrame gates on readiness alone; a dropped handle would still report success.
   private isRegisteredStream(stream: RemoteRuntimeMultiplexedTerminalState): boolean {
     return this.streams.get(stream.streamId) === stream
   }

src/renderer/src/runtime/remote-runtime-terminal-stale-stream-frames.test.ts

@@ -11,10 +11,8 @@ import {
 } from './remote-runtime-terminal-multiplexer'
 import { replaceRuntimeEnvironmentRevisions } from './runtime-environment-revision'
 
-// Why: STA-5098. `sendFrame` gates only on socket readiness, so a stream handle whose record was
-// dropped (close on park, or a reconnect that clears the stream table) still reported success on a
-// live socket. The host drops those frames for an unknown stream id, so the caller believed input
-// was delivered while the PTY never saw a byte and never painted — the revealed cold-parked pane.
+// Why: sendFrame gates on socket readiness alone, so a dropped stream handle reported success
+// while the host discarded the frames for an unknown stream id.
 
 type SubscribeCallbacks = {
   onResponse: (response: unknown) => void