Pin the capture-scope timeout floor, not just its wiring - #182

A 40 ms fixture pins the bound at "above 40 ms", and 45 ms is a live defect

The test added in #181 proves the preflight waits for its own answer, by having the stub take a real 40 ms. That pins the wiring. It does not pin the magnitude, and a post-merge validator on the app side found the gap: CAPTURE_SCOPE_TIMEOUT_MS = 45 typechecks clean and leaves the whole cli suite green.

45 ms aborts every real preflight there has ever been. Measured server-side over 1,271 production requests to this endpoint:

Every abort fails open by design, so the symptom is silent: captures are sent without asking whether the repository was excluded, and from the outside that is indistinguishable from the server having said "capture".

This is the fixture-grid trap in general form — a fixture can only ever pin a boundary it happens to straddle. So the constant is now exported and pinned from outside, as a floor rather than an equality: raising it is free, lowering it below the line is the defect. Equality would fail on any deliberate retune and teach the next person to edit the test in the same commit, which is how a guard becomes a formality.

Bisected across the floor, every value typecheck-clean

Full cli/src/*.test.ts: 954 pass / 0 fail. tsc -p cli/tsconfig.json: clean.

The behavioural test stays as it is. It proves the request actually waits; this one proves it waits long enough to matter. Neither is sufficient alone: the behavioural test misses 45, and the floor alone would pass on a bound that was never wired to the fetch at all.

Reasoning

_{written by the agent in-session via backthread/add-reasoning-to-prs}

Decisions

• The constant is now exported purely so a test can pin it from outside. A test that re-declares the expected value only compares the constant to itself, which is why the previous round left this gap.
• The floor is 5,000 ms, chosen against measured p99 (~1,700 ms) with roughly 3x headroom, not against the shipped 10,000. That keeps the guard meaningful if someone retunes the bound downward for a real reason.

Trade-offs

• The behavioural fixture stays at 40 ms rather than being raised above production p95. Raising it would pin the magnitude behaviourally but add well over a second to every suite run, and the exported floor gets the same property for free.

Limitations

• The floor is a static number in a test, so it does not track production latency. If this endpoint ever gets materially slower, 5,000 ms could stop being generous and nothing here would say so. Check: re-measure p99 if the preflight starts timing out in the field.