Testing helper: ephemeral-port fake HTTP server for backend tests (P2)

[turinglambdaai]

Found while auditing PodLens (turinglambdaai/podlens).

Problem

Every Rivet app's backend test suite needs a fake HTTP server (PodLens fakes the OpenAI ASR/chat endpoints and a podcast feed; Taskly/Fulcrum will need the same for their update/pipeline paths). Racket's racket/tcp offers no way to learn the port a listener bound — and app code ends up probing a hardcoded port range, which breaks under parallel CI or port collisions. PodLens currently does exactly that (tests/pipeline-test.rkt):

;; racket/tcp has no listener-port accessor; probe for a free port instead
(define port #f)
(for ([p (in-range 18432 18532)] #:unless port)
  (with-handlers ([exn:fail? void])
    (set! listener (tcp-listen p 16 #t "127.0.0.1"))
    (set! port p)))

Proposal

A small rivet/testing module (test-only, not embedded in the shipped app) providing something like:

(start-fake-http-server! handler) ; → (values port stop!)

where handler receives accepted ports (or a richer request/response shape). If a reliable listener-port accessor can be implemented inside Rivet (port-0 bind + extraction, or internal probing), expose that too — the point is that apps should not hand-roll port probing per project.

[turinglambdaai]

Technical correction for the implementation direction: Racket 9.3 can bind port 0 and report the selected listener port through tcp-addresses:

(define listener (tcp-listen 0 16 #t "127.0.0.1"))
(define-values (_host port _peer-host _peer-port)
  (tcp-addresses listener #t))

I verified that shape on Windows with the repository's supported Racket version; it returned the actual ephemeral port. The future rivet/testing helper should use this instead of probing a hardcoded range. Keeping the issue open because the reusable bounded HTTP request/response lifecycle, stop procedure, and tests are still useful work, but the listener-port extraction itself does not require internals or a new primitive.