Proposal: ship-adaptive-collection-rate-controller

The ChatGPT connector's adaptive collection rate controller is dressed in AIMD machinery that a hand-tuned floor disables. converge-provider-rate-governance correctly collapsed the two pre-flight waits into one (the AdaptiveLane is the sole send governor; GCRA pacing rides as a launchDelayHint), but three incidental constants and one cap-era policy still defeat the loop:

This change implements the defended SLVP-ideal verdict (docs/research/slvp-adaptive-collection-ideal-2026-06-11.md, 96% confidence) on top of the already-converged single-send-governor architecture (converge-provider-rate-governance). The binding-constraint mechanics are diagnosed in tmp/workstreams/adaptive-floor-diagnosis-2026-06-11.md (the 1500 ms jitter floor + ephemeral GCRA state) and tmp/workstreams/recovery-early-exit-diagnosis-2026-06-11.md (the self-terminating recovery exit). The architecture is settled; this change is parameterization + persistence + one policy fix + observability — not a redesign.

SHALL the polyfill-runtime's single pre-flight send governor take its inter-request rate from the folded GCRA pacing signal, NOT from a fixed launch-jitter floor. When a connector configures both a launch-jitter window and a GCRA pacing hint, the launch-jitter window SHALL be small enough (an ε anti-phase-lock noise band, on the order of tens of milliseconds) that it never exceeds the controller's learned inter-request interval. The send governor's pre-flight wait SHALL be the maximum of the ε-jitter and the pacing delay; since the ε-jitter is bounded well below the slowest learned interval, the learned interval is the binding rate authority whenever the controller has slowed below the ε band.