[unsupervised AI] Prototype bounded pre-submission permits

[YusefSyed]

Warning

This PR was written autonomously by an AI agent and has not been reviewed
by a human yet. Maintainers should ignore it until the human author has reviewed,
understood, and approved everything that the AI agent wrote.

Related to #8876 (the client-side submission stage), building on #8877.

A client can spend longer than the scheduler's idle timeout preparing a graph before update_graph reaches the scheduler. This experimental draft implements a finite pre-submission permit and an explicit protected compute/persist path. The scheduler acknowledges the permit before preparation starts. The client prepares the graph locally, rechecks the connection and deadline before sending, and exposes its newly-created Futures only after admission.

The path is opt-in: protected_compute and protected_persist live in a private module, support one collection per operation, and require manual scheduler-extension registration. Ordinary calls retain their existing path. The caller supplies lease duration, network timeout, clock-rate bound and margin; no production defaults or automatic coverage are proposed.

The protocol uses server-issued connection epochs, monotonic submission sequences, globally bounded pending permits, bounded retained outcomes per client, and a compacted deadline heap. Pending permits prevent idle shutdown and transfer into the existing active-update guard without an await gap. Expired, aborted, stale and reused submissions are rejected before graph work. The client releases only its operation-owned Future objects on rejection, preserving other Futures that share a key. Once dispatch is attempted, the outcome may be indeterminate: the client never aborts or resends that graph.

Validation on Python 3.12 / macOS arm64:

• 90 focused registry, scheduler, sync-client, async-client and legacy regression cases passed. This includes preparation over 400ms against a 50ms idle timeout armed at grant time, cancellation/connection loss before and after dispatch, delayed replies, shared-key cleanup, legacy same-ID cleanup with the extension disabled, and 20,000-operation expiry-index churn.
• 11 additional existing compute/persist/annotation/Future tests passed in focused runs.
• All repository pre-commit hooks passed via pre-commit run --all-files: Ruff 0.15.16 lint/format, codespell, and Mypy 1.20.2. The Pixi launcher was not used locally; the hosted platform matrix is running.
• Earlier resource-aware runs reported a one-FD finding in the process/client fixture and the existing reconnect test. Both reproduced with ordinary calls on unchanged upstream; those runs are not described as fully green.

Local measurements exposed an expiry scan that grew with every connected client. The bounded heap reduced the fixed-clock, 1,000-client status microbenchmark from about 108–132 microseconds to about 1.0–1.1 microseconds. Record-count bounds were checked separately from timing and tracemalloc observations. These are bookkeeping measurements, not network-capacity claims.

Sequential loopback measurements also make the API tradeoff visible: for the tiny graph case, median ordinary/protected API return was 0.43/11.13ms, while completion was 14.05/14.46ms (30 pairs). The protected return includes admission; the ordinary return only queues work. Larger graphs and a 4MiB payload were measured too, without claiming a speedup or a deployment-wide regression guarantee.

This remains a design prototype. The API shape, deployment clock assumptions, defaults and whether an opt-in surface belongs upstream need review. It does not automatically protect unchanged calls, define safe graph retransmission, or replace existing accepted-graph error semantics.

• Tests added / passed (focused cases described above)
• Passes pixi run lint

[github-actions]

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

    40 files  ±    0      40 suites  ±0   14h 38m 37s ⏱️ + 19m 39s
 4 248 tests +   88   4 066 ✅ +   86    178 💤  - 1  4 ❌ +3 
82 720 runs  +1 758  78 477 ✅ +1 758  4 239 💤  - 3  4 ❌ +3 

For more details on these failures, see this check.

Results for commit adca832. ± Comparison against base commit dc182bd.