fix(protocol): run shared standing-query evaluations one at a time, with at most one more pending - #355

…so request bursts cannot delay deltas

Every request, a one-row write included, takes a compute permit from one FIFO
semaphore, and holds it while it waits for its knowledge graph's commit. Standing-
query evaluations queued on the same semaphore, so under a write burst a refresh
waited behind every queued write (and writes behind every queued refresh): at 1,000
sessions, receipt writes spent p50 4.2 s waiting while the WAL persist took 1 ms,
and the probe's own write was 3 to 7 s old before any view could start on it.

Standing-query evaluations now run under a semaphore of their own, as wide as the
compute permits: a burst of writes or queries never delays a delta, and evaluations
never delay a request.

…ing else

96 sessions each subscribe to their own bound query (one parameterized family, as
voice-agent sessions do) while 32 writers commit receipts back to back; each receipt
is in every view's dependencies but changes no result. A prober changes one
session's result at a time. Every probe's delta must reach exactly its session,
once, within 5 s of the write's acknowledgement; no session may get a delta no
probe caused; every view keeps the agent contract (contiguous seq, increasing
revision, exact inserts and retracts) and ends equal to a fresh query.

The testkit agent gains poll_delta and clear_notices, so long-running agents can
poll without a 60 s timeout and without keeping every change notification.

…ir own query threads

…ing evaluations

…e doc

…_connection` (tests/ws_pipeline_tests.rs) relied on the host's core count. Commit 410425b splits the compute budget between requests and standing-query evaluations. On the CI runner the budget is about 2 permits, which leaves requests 1. The client's TRIANGLES query held that 1 request permit, so the other writer's `+seen(1)` queued behind it. The commit, and so the delta, came only after the long query finished. The production behavior is as the user decided; the test's setup no longer held on small hosts. It passed locally only because this machine has 32 cores. Violated invariant: the test fixture must give requests at least 2 permits so a writer can commit while a long query runs, on any host. The only place that sets this is `start_server`, which every test in the file uses. Fix: `start_server` now sets the budget explicitly with `with_compute_permits(COMPUTE_PERMITS = 4)`. The default half share gives requests 2 permits and standing queries 2, independent of the host. No production code changed. Verification: setting the budget to 2 permits (the CI case) reproduced the exact failure locally ("no delta while the query ran"). With the fixed budget of 4, `cargo test --test ws_pipeline_tests` passed 9/9 on three consecutive runs. `cargo fmt --check` and clippy are clean

…uery never blocks every write

Splitting the compute budget in half left a 2-permit host (4 or 5 cores, such as
the 4-vCPU CI runners) one request permit: one long query then held every write,
and every delta after it, behind it. tests/e2e_reactive's
agent_receives_deltas_while_its_own_long_query_runs failed pinned to 4 cores
and passed on main.

Requests now keep at least two permits whenever the budget has two, and
standing-query evaluations at least one, so a 2-permit host runs three
computations at once (one over its budget, only there); larger budgets split as
before. ws_pipeline_tests now runs on the smallest split budget (2), so per-PR CI
covers a request running beside a long query; it fails with the old split.

…e long query never blocks every write"

This reverts commit ae275cc304eb02ee680c06eaa2475e7e4c380b55.

…s_on_its_connection` (tests/ws_pipeline_tests.rs) relied on the host's core count. Commit 410425b splits the compute budget between requests and standing-query evaluations. On the CI runner the budget is about 2 permits, which leaves requests 1. The client's TRIANGLES query held that 1 request permit, so the other writer's `+seen(1)` queued behind it. The commit, and so the delta, came only after the long query finished. The production behavior is as the user decided; the test's setup no longer held on small hosts. It passed locally only because this machine has 32 cores. Violated invariant: the test fixture must give requests at least 2 permits so a writer can commit while a long query runs, on any host. The only place that sets this is `start_server`, which every test in the file uses. Fix: `start_server` now sets the budget explicitly with `with_compute_permits(COMPUTE_PERMITS = 4)`. The default half share gives requests 2 permits and standing queries 2, independent of the host. No production code changed. Verification: setting the budget to 2 permits (the CI case) reproduced the exact failure locally ("no delta while the query ran"). With the fixed budget of 4, `cargo test --test ws_pipeline_tests` passed 9/9 on three consecutive runs. `cargo fmt --check` and clippy are clean"

This reverts commit 0d50729.

…nd standing evaluations"

This reverts commit 410425b.

…ir own, so request bursts cannot delay deltas"

This reverts commit 21c693d.

…sts again

…rt deliveries during the load

…ration test