Intercept hot path blocks on full-table preprocess after each insert

[u2135]

Summary

Each successful intercept write synchronously calls preprocess_after_intercept_write() → run_preprocess() before the intercept path returns. Multiple outbound tool/API calls in one turn can compound latency (e.g. ~3× single-call cost).

Current behavior (SDK)

• src/provably/intercept/_storage.py: after commit, _write_row calls preprocess_after_intercept_write() on the same thread when row_id is not None.
• run_preprocess polls until status == "completed" with time.sleep(0.3) between polls.

Impact

• High latency on every intercept in workloads with many HTTP calls.
• Throughput limited by serial preprocess + global lock in preprocess_after_intercept_write.

Acceptance criteria

• Product/design decision: debounce, background queue, or “lazy preprocess” before handoff/proof only.
• If behavior stays sync: document expected latency model and tuning (when preprocess is unavoidable).
• Add metrics/logging hooks for preprocess duration per intercept (optional).

References

• src/provably/intercept/_storage.py — _write_row
• src/provably/handoff/_preprocess.py — preprocess_after_intercept_write, run_preprocess