fix(call-to-play): compact terminal histories

The 4,096-event store retained every completed call forever and local commands
only reported that they reached the queue. Once the bound was reached, GUI
actions could therefore fail with no user-visible result. The CLI snapshot wait
could also be satisfied by an unrelated live event.

Keep the complete event and chat history for every active call so late joiners
receive full context. When the creator starts or cancels a call, replace its
history with a single terminal tombstone; this bounds retained payload while
still healing peers that missed the live terminal action. Publish commands now
reply with the actual store result, and CLI snapshots use a direct reply.

Test Plan:
- `just fmt` -- passed
- `just clippy` -- passed
- `just test` -- passed, including full-cap terminal compaction
- `just build` -- passed
- `just peer-cli-tests S48` -- passed
- `git diff --cached --check` -- passed

crates/lanspread-peer/ARCHITECTURE.md

@@ -49,10 +49,17 @@ When a peer is discovered:
 ### Call to Play replication
 
 Call to Play is transient peer-session state rather than database state. The
-peer keeps a bounded event history, deduplicated by event ID. A local action is
-applied to that history, sent to the UI, and broadcast to every currently known
-peer. An incoming live event is applied once and sent to the UI without being
-rebroadcast, which prevents forwarding loops.
+peer keeps a bounded event history, deduplicated by event ID. Every event and
+chat message remains in the snapshot for the full lifetime of an active call,
+so a peer joining mid-call receives the complete context. A creator's `Start`
+or `Cancel` event replaces that terminal call with one small tombstone; this
+lets a peer that missed the live action heal on its next handshake without
+retaining the inactive call's full history. Active calls are never partially
+trimmed. If genuinely active history reaches the bound, local publishes return
+an error to the caller instead of appearing to succeed. A
+local action is applied to that history, sent to the UI, and broadcast to every
+currently known peer. An incoming live event is applied once and sent to the UI
+without being rebroadcast, which prevents forwarding loops.
 
 Actors are keyed by the peer's stable ID and carry a separate display name. The
 origin peer overwrites the actor ID on local actions, and live-event envelopes