v0.8.66: Correct approval UI copy for session-scoped approvals

[Hmbown]

Why this matters

The approval modal currently tells users that a / option 2 means "always" or "Approve always for this kind", but the runtime only approves matching tool calls for the current TUI session. That is a trust-boundary copy bug: users should be able to understand exactly how long an approval lasts before they press the key.

Current behavior

The compact approval controls hardcode the second action as "always":

• crates/tui/src/tui/widgets/mod.rs:1760-1772

The full approval option also uses the ApprovalOptionApproveAlways label:

• crates/tui/src/tui/widgets/mod.rs:1876-1879
• crates/tui/src/tui/widgets/mod.rs:1898-1899

But the runtime maps that option to a session-scoped decision:

• crates/tui/src/tui/approval.rs:1200-1204

And the TUI handler stores the tool/grouping keys in the in-memory session approval set:

• crates/tui/src/tui/ui.rs:9505-9512

Focused test evidence also matches session-scoped behavior:

• crates/tui/src/tui/approval.rs:2665 — benign_a_two_approves_for_session

Desired behavior

1. The compact and full approval UI should say "for session" / "this session" instead of "always" / "Approve always" for session-scoped approval.
2. Keyboard hints can stay the same (a, option 2) as long as the label is honest.
3. The copy should remain localized enough that non-English users are not told the approval is permanent.
4. Any docs/help text that describes the approval option should use the same session-scoped wording.

Repro or evidence

Open an approval prompt that offers the second approval option. The UI presents option 2 / a as always/permanent, while ApprovalOption::ApproveAlways maps to ReviewDecision::ApprovedForSession and is stored only in app.approval_session_approved.

Acceptance criteria

• Compact approval controls no longer render "always" for the session-scoped option.
• Full approval option text no longer renders "Approve always" for the session-scoped option.
• The chosen label clearly communicates current-session scope.
• Existing approval behavior remains session-scoped; do not accidentally persist this approval.
• Focused approval tests pass, including benign_a_two_approves_for_session.
• Add or update a rendering/copy test so this wording cannot regress.

Related

• Related: UX: make the approval modal's approve/deny key hints more prominent (good first issue) #3380, older approval-modal key-hint prominence work.

[Hmbown]

Implementation-scope note from local candidate triage:

The fix for this issue should stay narrow. The approval wording bug is real, but it should not carry unrelated release-bump, hotbar, or Agent-shell-default changes.

Recommended narrow scope:

• crates/tui/src/tui/widgets/mod.rs
• approval localization strings, if needed, for the full/compact approval labels
• docs/KEYBINDINGS.md only if it currently describes the misleading approval option
• keep the existing behavior test benign_a_two_approves_for_session
• add or update a render/copy test proving the UI says session / this session and does not say always / Approve all for session-scoped approval

Keep out of this patch unless there is a specific, reviewed reason:

• release/test-build version surfaces such as root Cargo.toml, Cargo.lock, crate Cargo.toml files, npm package metadata, generated web facts, README version bumps, root CHANGELOG.md, and release ledgers
• hotbar follow-through files such as crates/tui/src/commands/groups/core/hotbar.rs, sidebar/ui hotbar hunks, hotbar tests, docs/evidence/hotbar QA notes, and hotbar additions in README/config/keybinding docs
• Agent shell-default / approval-visibility work such as crates/tui/src/config.rs, crates/tui/src/main.rs, engine/tool-catalog/turn-loop changes, and related docs/MODES.md / docs/TOOL_SURFACE.md updates
• unrelated changelog churn, especially the currently observed local removal of the 0.8.52 section from crates/tui/CHANGELOG.md tracked separately in v0.8.66: Restore accidental TUI changelog 0.8.52 deletion #3768

Useful work in those other lanes can still land, but this issue is the trust-boundary copy fix. The PR should be small enough that a reviewer can confirm the UI wording now matches the already-session-scoped runtime behavior.