HTTP twin examples flaky in differential harness: .ospml binds same fixed port its .osp twin just released (no SO_REUSEADDR)

[MelbourneDeveloper]

Summary

The HTTP example twins (http_response_handle, http_server_example,
tui_repo_table) each bind a fixed port shared by the .osp and .ospml
twin (the port literal must match between flavors for [FLAVOR-IR-EQUIV]). The
differential harness runs the pair back-to-back, and the second (.ospml)
intermittently fails to reproduce the golden because the first twin's server has
not fully released the port (TIME_WAIT / no SO_REUSEADDR on the listen socket).

Evidence

• In isolation, every .ospml matches its golden byte-for-byte and produces
  stdout identical to its .osp twin:
  • http_response_handle.ospml → matches golden
  • http_server_example → .osp/.ospml byte-identical, both match golden
  • tui_repo_table → .osp/.ospml byte-identical, both match golden
• In a full-tree harness run, the same .ospml files intermittently FAIL
  (never the .osp — it runs first and gets the free port), which is the classic
  "second bind on the same port" race.

Root cause

Fixed server ports reused across the .osp/.ospml pair, plus no port-reuse
option on the listening socket in the C HTTP runtime (compiler/runtime/), so the
consecutive rebind races OS socket teardown.

Fix options

1. Set SO_REUSEADDR (and ideally SO_REUSEPORT) on the listen socket in the
   HTTP server runtime. Cleanest — ports stay identical, so [FLAVOR-IR-EQUIV]
   still holds and the race disappears.
2. Harness-level: retry an HTTP example once on bind failure, or add a short
   teardown delay between consecutive examples.

Note: the ports cannot differ between .osp and .ospml — that would diverge
the IR and break [FLAVOR-IR-EQUIV] — so "give each flavor its own port" is NOT a
valid fix.

Repro

zsh crates/diff_examples.sh        # full run: .ospml http twins flake
zsh crates/diff_examples.sh http   # subset: passes in isolation

Branch: prototyping.