fix(tui): auto-approve background tab permissions

[AidenGeunGeun]

Issue for this PR

Closes #44007

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Moves the existing auto-approval responder from the selected session route to the tab context. Auto mode now handles the selected session, open background tabs, and their child sessions. Permission state for open session families is refreshed after reconnect.

The responder remains event-driven and scoped to sessions owned by the current TUI tabs; it does not poll or scan all server sessions.

How did you verify your code works?

• bun test test/context/session-tabs.test.tsx (12 passed)
• bun typecheck in packages/tui
• repository pre-commit typecheck (33 packages passed)

Screenshots / recordings

No visual change. The regression test reproduces a permission request arriving for a background tab and verifies that auto mode replies without selecting it.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

PR #42310: fix(opencode): cascade auto permissions to subagent sessions
#42310

This PR appears to be related because it also addresses auto-permission handling for child/subagent sessions, which is similar in scope to the current PR's approach of extending auto-approval to background tabs and their child sessions.

However, #42310 focuses on cascading permissions to subagent sessions in the opencode package, while #44009 (the current PR) moves the auto-approval responder to the tab context in TUI. These may be complementary changes rather than duplicates.

[darellchua2]

We independently traced this on v2 stable (v2.0.18) before finding this PR — the described approach matches the root cause exactly. The responder living inside the session route means only the focused tab ever auto-replies; moving it to tab context and covering the open-tab session families plus reconnect refresh is the right scope.

One review question: in the v2.0.18 route code, the auto-accept effect only iterates permissions(). Form asks (data.session.form.list) and the interactive-question path aren't handled by that effect, and promptedPermissions is masked to [] under autoaccept, so nothing renders for those either. Does the tab-context responder here also cover form/question asks on background tabs, or would those still stall under --auto after this PR? If that's out of scope for this PR, I can file it separately.

For anyone else hitting this before this lands: running one TUI process per session (each with its own focused route) gives full parallelism under --auto on v2.0.18. I've been running as many as 7 sessions this way against a single main checkout without a single stall.