CL-6463: Fix connect-github card never flipping to connected on its own submit

[TheGreatAxios]

Summary

The owner-reported symptom: pasting a GitHub PAT into the in-room "Connect GitHub" card does nothing visible, even though Settings/Plugins shows GitHub connected and a live repro confirmed POST /connections/github/complete returns 200 and the credential row is written.

Root cause. ConnectGithubBlockContainer (packages/chat-ui/src/blocks/connect-github-block-container.tsx) read getConnectState once on mount and afterward only updated through subscribeConnectState's fold. connect-github-block.tsx's submit() on a successful token save only closed the inline field — it never called back into the container's state or triggered any refetch. The only fold source, applyConnectGithubSettingsEvent (connect-github-stream.ts), reacts to chat.settings events carrying template/pendingConnections/template/selectedRepos, which are written by the later, unrelated "start reviewing" PATCH — never by the PAT-submit/credential path. So a successful submit was structurally invisible to the card.

Fix. ConnectGithubBlockContainer now runs its own getConnectState refetch as the direct consequence of its own submit succeeding (submitAccessTokenAndRefresh), rather than depending on any host to fan the change out through subscribeConnectState. This is the only refetch outside the mount effect — every other update (repo-selection, start-reviewing, skip) still rides the existing subscription fold. One path only; no legacy branch left beside it.

What I verified

• Traced the real production host binding, apps/web/src/connect-github-actions.ts: its submitAccessToken already calls a local refresh() that fans out to the container's subscribeConnectState listener after a successful credential save. On today's main this specific host should already flip the card, given a working /github/state read. I could not reproduce the reported dead-card symptom purely by code trace against this file.
• However, ConnectGithubBlockContainer's contract does not itself guarantee this — it depends entirely on whatever ConnectGithubActions implementation a host supplies choosing to fan out on submit. The type's own doc comments (connect-github-actions.ts) even describe an alternate expectation (clearing template/pendingConnections on submit) that no implementation actually does. A container that self-sufficiently refetches after its own submit is correct regardless of host behavior, and is the fix that matches the ticket's own suggested shape ("give the container an explicit post-submit refresh that the submit path calls").
• Ran bun test for the full packages/chat-ui package: 651 pass, 0 fail (including the 2 new tests below).
• bun run typecheck and eslint/prettier clean for the touched files.

What I did not verify

• Live repro against the actual deployed symptom. I did not boot a stack (memory-constrained; another lane holds the live slot) and could not confirm this fix resolves the exact reported failure end-to-end in a running app — only that it closes a real structural gap in the container's contract. Live proof is still owed for this ticket.
• CL-6454 (MCP credentials launch-frozen). I searched this entire worktree for any trace of CL-6454 / "launch-frozen" handling and found none — it does not appear to exist in this codebase yet. I did not add any "can't act on this yet" messaging for a run started before the connect, since there's no existing signal in ConnectGithubQuery to detect that condition. If CL-6454 lands separately, this card will need a follow-up to surface that honestly.
• PR CL-6393: In-room connect cards for every preset, Gmail connector, resume-after-connect #165's connect-complete resume flow (packages/chat/src/connect-pending.ts's settleConnectedService, the generic connections/pending + "{service} is connected now — go ahead." message) is architecturally separate from this GitHub card's template/pendingConnections mechanism and was never unified with it. This PR does not unify them — it only fixes the card's own visible-state bug. Whether the room's agent actually resumes/wakes after a GitHub PAT connect (as opposed to the card visually updating) rides on that separate, unaddressed gap.

Tests

• packages/chat-ui/test/connect-github-block-container.test.tsx (new): mounts ConnectGithubBlockContainer directly against a fake host that resolves the token submit ok: true but never notifies subscribeConnectState — this fails against the pre-fix container (proven before implementing) and passes after, since the container now drives its own state off the submit's own result.
• Same file's failure-path test: a rejected token surfaces the inline error message and leaves the token field and submit button live, never a dead card.

Do not merge — reporting for peer review per the fix-lane process.