feat(fs): make session persistence authority explicit

[TZZheng]

Summary

• require every SessionCache to declare an explicit persistence role, with zero-safe NoPersist and MainAggregateWriter as the sole shared-aggregate writer
• enforce write authority inside both rewrite and append primitives while preserving in-memory ingestion and the independent completeness/truncation-safety contract
• keep current Main behavior explicit at all production and legacy fixture constructors, with focused role tests and fs/TUI ANATOMY updates

Why

Issue #645 needs detached/direct/cold cache views that can ingest session history without competing for the human-owned derived logs/session.jsonl aggregate. Completeness alone must never grant write authority; the Main aggregate owner must be explicit.

Test-first evidence

TestDetachedSessionCacheSteadyRefreshRemainsMemoryOnly was added and run against the exact original current-main base before production changes. It failed because a detached cache's steady Refresh updated memory and created the shared session.jsonl. After the role gate was implemented, NoPersist stays memory-only across full rebuild, explicit Persist, and steady refresh, while MainAggregateWriter retains the prior write-through behavior.

Validation

• focused persistence-role contract tests
• go test ./internal/fs -count=1
• go test . -count=1
• go test ./internal/tui -run '^$' -count=1
• go vet ./internal/fs
• exact rebased HEAD: 156f729d69a03f7b1b034eb252e0755f47855d4b
• exact base: e8eba00587c7659bdbe7bca82834f3c29c926fb4
• stable patch ID preserved across rebase: 5c84e9bbee7aa608da6633aa4f4eaedc1cb19a82
• independent exact-head Claude review: PASS
• independent exact-head Codex review: PASS

The publication rebase followed unrelated MCP migrate/preset changes in #661. The patch remained byte-identical, the changed path sets are disjoint, and both reviewers reran new-base compatibility checks.

Scope

This PR intentionally does not add direct-mail identity, durable unread state, or TUI switching behavior. Those remain separate changes in the #645 dependency chain.

Part of #645.