sec(hub): fail-closed freshness classification for future write-class channel tools (follow-up to #472)

[dp-web4]

Non-blocking note carried from Legion's review of #472 (thread sec-mesh-freshness):

channel_tool_requires_freshness() is an allowlist of writes — a future write-class tool added to dispatch_channel without touching this list silently inherits read-class tolerance (fail-open for new writes).

Two cheap hardenings, either works:

1. Invert it: allowlist the reads, default-require freshness for anything else — fail-closed for new tools, and the read set changes rarely.
2. Keep as-is + guard test: a test that walks the dispatch arms (or a const list beside them) and asserts every non-read tool is in the freshness set, so adding a write without classifying it breaks the build.

Option 1 is the stronger default; option 2 is the smaller diff. Not a merge blocker for #472 — this is Phase-2 follow-up hardening.

Refs: #472, private-context/security/gpt-review/H007-H008-mesh-freshness-legion-reply3.md