refactor(tui): extract 600-line Update method into per-message handler functions

[jongio]

Summary

The Model.Update method in internal/tui/model.go spans 604 lines (lines 387–991) with a single switch statement covering 50+ message type cases. This is a textbook Long Method smell — over 12x the recommended 50-line threshold.

Why This Matters

• Readability: Developers must scroll through 600 lines to find the handler for a specific message type.
• Merge conflicts: Any two features that add or modify message handling will conflict in the same function.
• Testing: The method cannot be unit-tested per message type — only the entire Update flow.

Current Structure

The switch statement handles messages in these groups:

Group	Approximate Lines	Cases
Background color / resize	387–405	2
Spinner tick	407–411	1
Store lifecycle	413–440	3
Session loading	442–560	6
Detail loading	562–595	3
Attention / plan scanning	597–680	8
Work status	682–780	6
Copilot SDK	782–860	5
Search	862–920	4
Config / reindex	922–965	5
DB watcher / keys / mouse	967–991	4+

Suggested Refactoring

Extract each logical group into a dedicated handler method:

1. handleStoreMsg(msg) — store open/close/error
2. handleSessionMsg(msg) — session loading, grouping, filtering
3. handleDetailMsg(msg) — detail loading, plan content
4. handleAttentionMsg(msg) — attention and plan scanning
5. handleWorkStatusMsg(msg) — work status scan chain
6. handleCopilotMsg(msg) — SDK init, search, streaming
7. handleSearchMsg(msg) — deep search ticks, debounce
8. handleConfigMsg(msg) — config save, reindex

Each handler returns (Model, tea.Cmd) and is called from a streamlined Update that dispatches by message group.

Smell Categories

• Bloaters → Long Method (604 lines, threshold: 50)
• OO Abusers → Switch Statement (50+ cases in a single type switch)

[jongio]

Consolidated into a single tracking issue.