Bug: channel unread is flaky after MCP/session restart and can ignore prior join state

[laynepenney]

Problem\nThe #dev unread flow is flaky across tool/MCP restarts. In this session, recall_channel.unread returned No channel memberships -- join a channel first. immediately after a successful join, while a direct read fallback still worked.\n\nThis makes the unread poll loop unreliable and forces channel reads as a workaround.\n\n## Why this matters\n- unread is supposed to be the lightweight polling primitive for agent loops\n- when it flakes, agents lose reliable coordination state\n- the failure mode is silent enough that it can be misread as "no work" instead of "broken unread state"\n\n## Observed behavior\n1. join #dev\n2. call unread\n3. receive No channel memberships -- join a channel first.\n4. direct read still returns channel content\n\n## Suspected area\nLikely mismatch between durable membership state in the channel DB and whatever membership/session state the MCP unread path is consulting after reconnect. This may be adjacent to the membership/presence split and dirty-flag polling work (recall#638 / recall#639).\n\n## Acceptance\n- unread works immediately after join\n- unread keeps working after MCP/server restart without requiring a manual rejoin when durable membership exists\n- tool-level unread behavior matches direct channel DB state\n- add regression coverage for restart/rejoin/unread across the MCP wrapper path\n\n## Notes\nThis issue was surfaced during active dev-loop use, not synthetic testing. Treat GitHub issues/PRs as source of truth if channel posting gets flaky again.

[laynepenney]

Adding the concrete regression surface from the current code:\n\nThere are really two failure modes to gate here:\n\n1. membership/cursor continuity across restart\n- unread must respect durable memberships/cursors after MCP/session restart\n- if durable membership exists, restart should not require a manual rejoin just to make unread work\n\n2. SessionStart/startup must not consume unread as a side effect\n- current cmd_hook startup path in synapt/src/synapt/recall/cli.py still summarizes channel state by calling channel_read("dev", ...) after checking counts\n- that advances the cursor and can clear the very unread state the polling loop is supposed to consume\n- startup/session-resume should use a non-consuming preview path, not channel_read()\n\nSuggested acceptance additions:\n- add regression coverage for join -> restart -> unread through the CLI/MCP wrapper path, not just direct channel.py calls\n- add regression coverage proving SessionStart/startup preview does not advance channel cursors\n- add regression coverage for the case where read can still see messages but unread incorrectly reports no membership\n\nRelease impact: this is part of the gr2 0.1.0 runtime seam, not a side bug, because the playground and migration loops depend on unread being trustworthy after restart.