perf(sessions): batch runtime event sequence allocation

[Yevanchen]

Closes YEF-1081

Summary

• Batch one-event-per-session sequence allocations into bounded D1 updates.
• Preserve ordinary versus terminal lifecycle write admission while respecting D1's 100-parameter limit.
• Add regression coverage for 98 mixed-status sessions and allocation batch shape.

Why

• Runtime state operations fan out one event per target session.
• The allocator previously awaited one D1 update per session, producing O(s) remote round trips before the already-batched insert.
• The new allocator sends bounded bulk statements in one D1 batch; for 98 mixed-status sessions the test observes 3 allocation statements in one batch instead of 98 individual awaits.

Verification

• Commands:
  • just check
  • just test-file apps/api/tests/session-runtime-event-store.test.ts
  • just test-file apps/api/tests/runtime-state-operation-target-events.test.ts
  • just tc-package @mosoo/api
  • bun run --filter @mosoo/api lint
• Manual steps: N/A
• Not run: N/A

Impact

• User/API/contract changes: None; persistence results and write-admission rules are unchanged.
• Generated files / GraphQL / DB / lockfile: None.
• Env or config changes: None.
• Risk and rollback: Low. Bulk updates use existing D1 batch/RETURNING behavior and preserve retry/skip semantics; revert the commit to restore per-session allocation.

Review

• Closest review areas: multi-session runtime state operations, terminated-session lifecycle markers, D1 allocation chunking.
• Known trade-offs: Statement work remains linear and is chunked at 96 session IDs; the improvement removes per-session network round trips rather than eliminating per-session database work.