feat(collaboration): persist activity/notification history and add invitation list+respond endpoints #16460

Problem

#16443 wires the collaboration UI onto real backend surfaces (api/collaboration.py's REST API + websocket/presence.py's presence WebSocket), but two capabilities have no persistence or listing surface at all — accepted as live-only for #16443's first pass, tracked here as the fast-follow.

1. Activity feed and secret-share notifications are ephemeral. impl gap: wire in the real-time collaborative-session UI (#608 phases 5-7 / #874) — 6 components + useSessionCollaboration, zero callers #16443 delivers both over the presence WebSocket's existing generic {"type": "broadcast", ...} relay (websocket/presence.py's PresenceManager.broadcast_to_session). That relay only reaches clients connected at the moment of the broadcast — nothing is written to a database. A user who reconnects, or wasn't connected when an activity happened or a secret was shared with them, sees nothing: no history, no "you missed 3 notifications while away."

2. There is no REST endpoint to list or respond to a pending invitation. models/session_collaboration.py's SessionCollaboration model already supports this (invitations: Mapped[dict], add_invitation(), remove_invitation()), and api/collaboration.py exposes POST /{session_id}/invite (the owner's send side), but there is no GET /{session_id}/invitations (list mine) or POST /{session_id}/invitations/{id}/respond (accept/decline) endpoint. impl gap: wire in the real-time collaborative-session UI (#608 phases 5-7 / #874) — 6 components + useSessionCollaboration, zero callers #16443 therefore drops pendingInvitations/respondToInvitation from useSessionCollaboration.ts's public surface rather than shipping a fake stub — an invited user has no way to see or act on an invitation today, in any client.

Fix

• A small persistence layer (a table, or reuse SessionCollaboration.collaboration_metadata's JSONB) for activity events and secret-share notifications, plus a GET /{session_id}/activity and/or GET /{session_id}/notifications endpoint with pagination, so a reconnecting client can backfill.
• GET /{session_id}/invitations (current user's pending invitations across sessions, or scoped to one session) and POST /{session_id}/invitations/{invitation_id}/respond (accept/decline), wired to the model's existing add_invitation/remove_invitation methods.
• Once these land, restore pendingInvitations/respondToInvitation to useSessionCollaboration.ts backed by the real endpoints.

Acceptance criteria

• A client that reconnects mid-session sees activity/notifications it missed, not just live ones from that point forward
• An invited user can see and respond to a pending invitation from at least one client
• useSessionCollaboration.ts restores pendingInvitations/respondToInvitation backed by the new endpoints

Discovered During

#16443 (wiring the collaboration UI onto the real backend).