fix: reduce session event query load

[yuezengwu]

Summary

A session notification currently recomputes whole-chat agent status and invalidates both event timelines on every frame. The chat event query also processes historical payloads through window functions before enforcing the per-speaker page limit. This change reduces that repeated work while preserving status, pagination, and authorization behavior.

• Throttle event timeline invalidations independently by chat and agent/chat pair, with an immediate leading refresh, a one-second window, and a trailing refresh. Clear timers on org changes and teardown; keep immediate status cache patches.
• Enrich WS session frames only when this process has an eligible audience socket, and resolve only the frame's agent. Intersect targets with speaker membership and push exact pair predicates into the relevant database reads. Keep the existing delivery-time authorization checks.
• Read each speaker's bounded event window separately from current-turn metadata within one SQL statement. Preserve MIN(created_at), window-independent turnStartedAt, ordering, and cursors.
• Skip Q3 narration and turn-end lookups when the actual latest event cannot produce a fresh activity. Preserve application-clock freshness and provider retry semantics.

Validation

• pnpm check — exit 0; existing repository diagnostics remain. Touched-file checks are clean.
• pnpm typecheck — all 9 Turbo tasks pass after completing the Antigravity test fixture with its required noteTurnStart mock. The original CI failure was a baseline fixture omission; the interface and runtime implementation remain unchanged.
• env -u CI_DATABASE_URL -u DATABASE_URL VITEST_MAX_FORKS=1 pnpm test — exit 0, 10/10 Turbo tasks successful (4 cached). Server: 3,507 passed; Web: 2,434 passed; Client: 2,893 passed and 7 skipped. Remaining package and CLI batches pass. This full local run was on 75752f5ac; the fixture-only follow-up passes its 14 Antigravity handler tests, and the complete GitHub CI run passes on f99e588d5 (lint/typecheck, Server, Client/Web, both CLI shards, and smoke checks). CodeQL also passes.
• Focused regression: 115 server tests across six files and 26 Web WS tests across two files. Covers event pagination/turn metadata, target pair scope, retry recovery, freshness, audience/membership isolation, burst/trailing invalidations, eviction, and org changes.
• Real PostgreSQL comparison: invoke the baseline and candidate service functions through Drizzle/postgres.js on identical synthetic fixtures, compare complete DTOs, and capture actual EXPLAIN (ANALYZE, BUFFERS) plans. All comparisons pass for DESC 200, ASC 2, full status, and targeted status projection.

Local PostgreSQL 17.10, 2 CPUs, 1 GiB RAM, 256 MiB shared buffers, 4 MiB work_mem, existing repository migrations/indexes. One warmup plus seven measured executions per version, alternating order. Median database execution times for eight agents with 12,000 events each:

Query	Before	After	Evidence
Q1 chat event window	292.594 ms	20.158 ms	Temp read/write blocks fall to zero
Q2 WS target status reason	18.445 ms	2.423 ms	Shared hits: 17,236 → 2,154
Q3 WS target activity	1.900 ms	0.232 ms	Shared hits: 3,185 → 399

In a separate fixture with an old narration and latest error, full Q3 drops from 26.620 ms to 0.071 ms; both narration and turn-end subplans have zero execution loops in every candidate sample. All three Q1 fixtures have zero candidate temp I/O. Full-chat Q2 remains approximately unchanged; Q1's timestamp metadata seek still filters historical rows and can increase shared-buffer hits despite the lower execution time. Synthetic local results do not establish production CPU savings.

Change Surface

• Server chat event/status services and admin WS enrichment
• Web WS event timeline cache invalidation
• Public CLI, tree onboarding, skills, packaging, or release behavior
• Database schema, indexes, migrations, or persistence semantics

Notes

• No package/install changes or new database indexes. Also complete the existing Antigravity SessionContext test fixture so the repository typecheck gate can pass.
• QA scope: focused local queries and deterministic product regressions. Related cross-surface case: packages/qa/cases/runtime/provider-owned-turn-status.md; live provider/browser validation was not run, and this is not deployment qualification.
• Follow-up: evaluate kind-filtered access paths and Q1 metadata scans using representative plans. Consider WS computation coalescing only if residual notification rates justify the additional ordering and trailing-update logic.

Adversarial verification

Reviewed head: f99e588d591619d0ea5fd729d2a90a82d6c4c28c. No blocking regression found in the changed paths.

• Real PostgreSQL differential checks across 20 deterministic randomized fixtures: 400 Q1 comparisons against both the baseline and an independent in-memory oracle; 520 full/targeted/batch status comparisons. Covered both sort directions, clamped limits, more than 1,000 events, sequence gaps, nonmonotonic timestamps, two database time zones, unknown/terminal events, stale/future timestamps, missing/evicted sessions, speaker/watcher/human membership, cross-org Q1 exclusion, and absent/empty target sets.
• Adversarial Web probes passed with a real QueryClient/QueryObserver: a slow older request cannot overwrite the trailing refresh result, and old-socket late frames plus old event-timeline timers do not affect the replacement org connection. The matching Web run passes 28 tests; the focused PostgreSQL/WS regression run passes 115 tests.
• Production source remained unchanged and matches the recorded query benchmark hashes. Temporary test files were removed and synthetic database rows reset.
• Residual performance costs remain as described above: full-chat Q2 scans and Q1 turn metadata still need separate access-path evaluation. These checks do not establish a production CPU reduction or replace live provider/browser acceptance.

Merge readiness is still gated by the repository's required Code Owner approval; no approval is claimed by this author-side adversarial verification.