Slack bot: persist thread-to-session bindings across restarts

Summary

Persist the mapping between Slack conversations and Mecatl sessions so a bot
restart can resume an existing conversation.

The bot currently stores this mapping in process memory. After a restart, a
message in an existing Slack thread creates a new Mecatl session even when the
previous session remains available on the server.

Scope

• Define a durable record for the Slack team, channel or DM, thread, and
  Mecatl session identifier.
• Preserve the current one-session-per-DM and one-session-per-channel-thread
  behavior.
• Validate the recorded session through the SDK before reuse.
• Define behavior for missing, deleted, inaccessible, terminal, and stale
  sessions.
• Prevent one Slack conversation or principal from adopting another
  conversation's session.
• Make updates atomic enough that a crash cannot silently bind a thread to an
  unrelated session.
• Add restart and stale-record tests.

Completion criteria

• Restarting the bot preserves multi-turn context for a valid Slack
  conversation.
• Invalid records fail closed and create a fresh session only under the
  documented recovery rule.
• Concurrent messages cannot produce conflicting durable bindings.

References

• #883 and the session-map TODO in
  sdk/typescript/examples/slack-bot/src/bridge.ts.
• The Slack bot integration roadmap parent.

Fully or partially written by an AI agent.

Start with the session-map TODO and Slack bridge in sdk/typescript/examples/slack-bot/src/bridge.ts, then review issue #883 and the SDK session-validation path. Define the durable binding and recovery behavior for missing, inaccessible, terminal, or stale sessions, and add restart, stale-record, and concurrency tests. Done means valid conversations resume safely while invalid or conflicting bindings fail closed.