CRDT capacity benchmark and resource observability

[brylie]

Establish a measured operating envelope for Compendium before and during #13s CRDT-sharding work. This complements #24, which is specifically production sync-latency observability; this issue covers state size, memory, initial sync, broadcast fan-out, and recovery behavior.

• Build repeatable seeded-workspace scenarios spanning documents, blocks, Collection rows, edit churn, concurrent browser clients, and representative MCP agent write bursts
• Measure per workspace/shard: encoded CRDT state size, cold-load and initial-sync bytes/latency, server heap, client heap, CPU/event-loop delay, update-apply latency, WebSocket fan-out bytes, and snapshot/restart time
• Record an initial sizing envelope and SLO-oriented thresholds that trigger sharding, partitioning, compaction, or capacity work. Do not adopt arbitrary universal record-count limits without measurement
• Compare the current global-document baseline with the Y.Doc sharding strategy for multi-space #13 shard design and publish the results in a durable engineering note
• Add a bounded benchmark/regression check suitable for CI, with larger scenarios runnable on demand
• Feed the live sync-latency dimension into Sync-latency observability #24 rather than creating a second competing latency metric

Done when: maintainers can reproduce a representative CRDT load profile, see where memory/network/recovery costs grow, and make #13 implementation decisions from recorded measurements rather than intuition.

Run before finalizing #13s shard boundary; keep the resulting ongoing latency signal aligned with #24.

[brylie]

Promoted P2 → P0: #13 (Y.Doc sharding strategy, also P0) is explicitly sequenced after this — its own body says "use #31 to validate the choice" and "Run before finalizing #13's shard boundary." #13's shard model can't be picked from measurement rather than intuition until this benchmark/sizing work lands, so it can't sit at a lower priority than the work it blocks. Marked as blocking #13 accordingly.

[brylie]

Relationship: #112 is blocked by this benchmark. The 0.3.0 shard design must use the measured baseline and thresholds from #31 rather than choosing a replication boundary by intuition. Sequencing: #31 → #112 → #113 → #114 → #6.