#3399 serve: the per-IP WebSocket burst limit can't be configured, so workers behind one NAT IP throttle each other

Problem

swamp serve rate-limits WebSocket connections per source IP ("WebSocket IP burst rate-limited from "). There is no flag or serve.yaml setting for it: no limit, no window, no exempt CIDRs, and authenticated workers aren't treated differently. --trust-proxy only changes which IP gets counted.

Many workers can share one source IP. Cloud NAT, a corporate egress, or a Kubernetes node all do this. When they do, serve treats them as one client and throttles them all together, even though every connection presents a valid worker token.

What we saw (ops.swamp-club.com)

• Serve 20261013.004531.0-sha.1373120f; workers 20260928.201643.0-sha.6a1df41a.
• One UAT run used 34 GCE worker VMs. All of them reached serve through the public load balancer and left through one Cloud NAT IP.
• Between 19:27 and 20:56 UTC, serve logged 11,977 WebSocket IP burst rate-limited lines, all from that IP. The rate climbed to about 2,300 per 10 minutes as the run went on.
• In the same window serve logged Authenticated token "uat-worker" 3,982 times, about 117 per worker. The workers were connecting and reconnecting, and the limiter kept refusing them.
• Effect on one shard:
  • its dispatch reached the worker about 7 minutes after the step started (enrolled 19:30:28, dispatch received 19:37:17);
  • the worker finished at 19:42:48, but serve recorded the result at 19:54:50, 12 minutes later.
• Shards then failed with The operation was aborted due to timeout. A suite that takes 10–15 minutes on GitHub runners was still unfinished after 90 minutes.
• Nothing in the run's output said it was being rate-limited. The only sign was serve's own journal.

Our workaround: workers now connect to serve inside the VPC, so each has its own source IP. That isn't possible on every network.

Proposed

Any of these would help, and they can be combined:

1. Make the burst limit configurable in serve.yaml and with flags: the limit, the window, and a list of trusted or exempt CIDRs.
2. Key the limit on the credential, not the IP, once a connection authenticates. A valid worker token shouldn't share a budget with every other client on the same IP. #1615 did this for the auth-failure limiter.
3. Tell the client it's being rate-limited. Close the socket with a clear code or Retry-After. The worker should log it and back off, instead of reconnecting in a tight loop and making the burst worse.
4. Report it to operators. Expose a rate-limited count per IP in metrics or swamp worker list, so it shows up without reading the journal.

Related: #1615 (the auth limiter keyed by IP blocked users sharing an IP; fixed for auth failures, not for this connection burst limit).