fix(gui): recover stale queued messages

[rainstorm0907]

Summary

• advance the pinned T3 source to cc839c42, which includes upstream client-side queued messages from feat(web): queue messages sent client-side while the agent is working pingdotgg/t3code#11673
• detect the legacy isStreaming=false && pendingMessageCount>0 state without silently clearing it
• let the user resume recovered text in original queue order or explicitly discard it
• keep unsent recovered text available when replay fails

Why

The old desktop sent follow-ups directly into Pi while a turn was running. If that turn stopped before the provider drained its queue, T3 showed the session as ready while Pi still reported pending input, so later sends could hang indefinitely.

The upstream client queue prevents new occurrences. The bridge recovery prompt repairs already-stranded sessions without executing old input on attach or deleting it without a choice.

Verification

• node --test harness/t3-integration/test/bridge.test.mjs — 27 passed
• node --test harness/t3-integration/test/*.test.mjs — 34 passed, 5 source-dependent tests skipped
• exact cc839c42 overlay apply — passed
• exact-source apply/idempotence/remove/dirty-guard test — passed
• git diff --check — passed
• live Maplog recovery — provider queue went from 3 messages to 0; replacement recovery session is actively running tools

Review follow-up (this branch)

• resolveQueueRecovery opened a projection turn before its first send, and applyState reads running off projection.turnId. A transport failure on the very first recovered message left that turn open forever: the thread reported running with nothing behind it and accepted no further input. sendTurn already guards the same shape. Added the matching catch and a regression test — the pre-existing failure test fails on the second message, where a real turn is running and the hole does not show.
• node --test harness/t3-integration/test/bridge.test.mjs — 33 passed; the 2 failures need a local T3 source checkout and fail identically on cbb13a29a
• node --test harness/t3-integration/test/*.test.mjs — 40 passed, 5 skipped, same 2
• node --test harness/pi-server/test/restart-profile.test.mjs — 3/3 on macOS
• git diff --check — passed

Notes

Full journey and residual legacy-attachment limitation: cycles/2026-09/wk3/09-15/1716-t3-queued-message-recovery-wrap.md

CI note

checkpoint was red on the isolated Pi server test restart-profile.test.mjs
(reason: "no-pid"). That workflow only runs on pull_request and on pushes to
codex/dual-runtime-checkpoints-20260913, so it has never run on rubato/base
and there was no base run to compare against. The failing test arrived with
40b620b5b on base two hours before this PR's run, and this PR changes no
harness/pi-server/**.

The cause is now fixed on base in 0cc633236: pgrep -l lists the full command
line on BSD and only the process name on procps, so -lf output that reads
node .../cli.mjs --agent-dir X on macOS reads 1234 node on Linux and never
matches cli.mjs. listenerPid now takes pids from pgrep -f and reads each
command line with ps. This branch has merged that base commit.