[trissim]

The ordinary compiled-pipeline client sleeps for the generic 0.5-second interval before each completion status poll, adding detection latency after both compilation and execution. This PR uses a 0.05-second interval for those two waits while leaving the generic zmqruntime default intact. Refs #182.

On matched CPU-only official30 1w_1t fresh-server runs, receipt-level client wait slack fell from 13.827 to 1.554 seconds. The sum of per-observation total time fell from 274.266 to 263.374 seconds (10.892 seconds; 26/30 cases faster). Server compilation was 83.759 vs 83.733 seconds, and server execution was 89.219 vs 90.693 seconds; the latter +1.474-second difference may be variation or polling contention and is not claimed as an execution-only improvement. All 30 cases passed and all 110 output files were byte-identical. The candidate total is 0.497 seconds below the native CP 5× total-phase reference line, although the tools' total timers have different preparation boundaries.

The committed report, CSVs, and regenerated figure are in benchmark/results/perf_fast_poll_20260929/. Validation: 80 focused unit/integration tests, Black, and diff checks passed on this PR branch.

This PR is based on #180 because its lazy-catalog run is the matched control. The remaining direct completion-detection slack is about 1.55 seconds across official30; an event-driven zmqruntime wake-up can be considered separately if it measurably improves the dominant path.

Closes #182.