[edwin-zvs]

Problem

Switching to a session sometimes showed `(no PTY history yet — interact to populate)` even though the session had history. Pressing any key made it appear — because a live PTY event lazily recreates the history entry (`histories.entry().or_default()`), so the entry had been genuinely absent until then.

Root cause

The history entry could go missing after a switch and never get refetched:

1. Trigger too narrow. Hydration only fired while the transcript was stale (`transcript_session != selected`). Once the transcript hydrated, it never re-fired. So if the history entry was later dropped — e.g. a `SessionEvent::Reset` removes it but leaves `transcript_session` unchanged — the Terminal view stayed stuck on the placeholder.
2. `needs_history` gated on `has_pty`, read at request-build time. A reconnecting adapter is transiently `has_pty == false`, so the PTY fetch could be skipped while the view was already Terminal — and then never retried (per Add in-app text selection for TUI copy #1).

Fix

Make hydration self-healing: trigger — and fetch the PTY snapshot — whenever the Terminal view has no history for the selected session, driven by the view rather than `has_pty`. The fetch always inserts an entry (empty if the replay is empty), so the condition clears after one pass — no spin loop. This also covers the `has_pty`-flip race at the first hydration, since the fetch no longer depends on `has_pty`.

No behavior change for the common path: a freshly-selected PTY session still fetches history exactly as before (view is Terminal); non-PTY/Transcript sessions never fetch.

Test

• `terminal_view_rehydrates_after_history_dropped` — drives a real `SessionEvent::Reset` through `on_notification`, asserts the history entry is dropped, that this re-triggers hydration (the old transcript-only trigger would not have), that the request actually fetches the PTY snapshot, and that Transcript view does not spin up fetches.
• Full suite green: 130 unit + 1 integration.

🤖 Generated with Claude Code