fix: Harden TUI terminal restore during shutdown (#13220)
## Why
Users occasionally end up with a corrupted terminal after quitting the
TUI (stuck in the alternate screen, mouse wheel acting like arrow keys,
raw mode left on). See the recent reports on #8860. The terminal restore
sequence was a `?` chain, so a single failed write — easy to hit when
the terminal is being torn down during a racy shutdown — aborted all
remaining restore steps, and nothing re-attempted restoration on a
non-panic exit.
## What
- `leave_alt_screen` and `final_cleanup` are now best-effort: every
restore step runs even if an earlier one fails, and the first error is
still surfaced. Mouse-capture disable and `LeaveAlternateScreen` are
issued as separate commands so one failing cannot block the other.
- Terminal-state flags (`TUI_ACTIVE`, `RAW_MODE_ENABLED`,
`MOUSE_CAPTURE_ENABLED`) are only cleared when their corresponding
restore step succeeds, and are set optimistically in `enter_alt_screen`
so partially-applied startup still gets cleaned up.
- `run_app` gained a safety net: after cleanup it calls
`restore_terminal_best_effort()` (renamed from
`restore_terminal_on_panic`, since it is no longer panic-only), which
re-restores via raw escape sequences if any state flag is still set.
This is a no-op when cleanup fully succeeded.
## How
The failure mode is inherently racy and hard to reproduce; the hardening
guarantees that `LeaveAlternateScreen` and `disable_raw_mode` are always
attempted at least twice (crossterm path, then raw-escape fallback)
before exit. Reviewers can simulate the old failure by making
`terminal.clear()` error: previously that skipped every subsequent
restore step.
