refactor(tui): centralize terminal session lifecycle

[CnBarrier404]

Summary

• introduce a terminal session boundary and semantic lifecycle hooks
• move repository initialization and update checks out of terminal navigation
• replace the task runner with direct async event flows and simplify page orchestration
• update architecture documentation and affected tests

Testing

• Not run as part of PR creation

[CnBarrier404]

Review notes — ChatGPT

I reviewed the current PR, including the TUI lifecycle refactor and the latest follow-up commit. CI is green, including the NativeAOT publish check, and the overall direction of moving startup/recovery concerns out of TerminalNavigator looks cleaner.

There is one behavior regression I would fix before merging:

Blocking application work now runs on the TUI thread

Removing TerminalTaskRunner changed several page operations from “run the whole request off the UI thread, then marshal the result back” to directly awaiting IRequestDispatcher.DispatchAsync(...) from Terminal.Gui event handlers.

That is safe only when the request handler yields quickly. Some handlers do not. For example, InspectAssetsHandler.HandleAsync performs List(...) / Fields(...) synchronously and only then returns Task.FromResult(...). List(...) reads the assets file and may call ReadField for every listed asset. With the new InspectAssetsView.InspectListAsync / InspectFieldsAsync flow, that synchronous work executes on the Terminal.Gui event-loop thread, so sufficiently large files can freeze input and stop the working indicator from updating.

The same pattern exists in other synchronous request handlers such as repository recovery/management and listing installed mods, so I would keep the new async flow structure but introduce a thin offload boundary for application operations whose handlers can do synchronous I/O/CPU work (for example, starting the dispatch from Task.Run with the page lifetime cancellation token), rather than bringing the old callback-oriented TerminalTaskRunner back wholesale.

Update-check lifecycle

The current MainMenuView still ties update checking to each view instance, so returning to the main menu can restart the check and leaving it can cancel an in-flight one. Given the planned page split into view + logic, I would not block this PR on that architectural placement. The newly added TODO is enough to keep the intended session-scoped, once-per-terminal-session behavior visible for the follow-up refactor.

Other than that, I did not find another issue I am confident enough to call a merge blocker in the new TerminalSession stop/cancellation flow, repository initialization flow, or page lifetime cancellation changes.