Triaged a Slack thread from nelson reporting intermittent connection-
migration failures and got concrete data from the prod us-linode-nj
egress: 13/15 successful migrations over 24h, with 2 failures all
matching "createOrMigrate error: path probe error: context deadline
exceeded". PR #301 (where migration was first implemented) didn't add
any tests, so we have no regression coverage on the load-bearing
quic-go AddPath/Probe/Switch contract.

Adds two tests in egress/migration_test.go:

- TestConnectionManager_Migration_HappyPath establishes a QUIC
  connection over a UDP loopback path A, then calls createOrMigrate
  again with the same CSID over a different UDP loopback path B and
  asserts the migration branch returns the SAME *quic.Conn (not a new
  one) and that a fresh stream opens cleanly over the migrated
  connection. End-to-end exercise of the AddPath → Probe → Switch
  triple via real packets.

- TestConnectionManager_Migration_ProbeTimeout pins down the failure
  contract: when the new path's WriteTo silently drops everything,
  PATH_CHALLENGE never reaches the consumer and createOrMigrate must
  surface the timeout as an error within ~probeTimeout (not hang),
  and must leave the connection record in cm.connections so the next
  attempt can retry. This is the exact failure mode seen in prod, but
  here we know the cause (we're forcing it).

Both pass in 0.01s and 1.5s respectively, and `-count=5` is stable.

To make the test feasible without standing up a full WebSocket, this
also relaxes createOrMigrate's parameter type from
*errorlessWebSocketPacketConn to net.PacketConn. The function only
read pconn.addr for logging, now uses pconn.LocalAddr() instead.
errorlessWebSocketPacketConn already implements net.PacketConn so no
production caller needs to change.

What this rules out: if a future quic-go bump regresses the AddPath /
Probe / Switch API contract, these tests fail at the failing step (the
error string names which sub-API broke). Currently both pass under
quic-go v0.59 + the rebased fork patch, so the prod failures Nelson
saw are NOT coming from the quic-go API layer — most likely candidate
is consumer-side QUIC connection-state GC during the WebRTC re-pair
window (MaxIdleTimeout=60s, KeepAlivePeriod=15s; if the re-pair takes
long enough the consumer's listener side drops the connection state
before the new producer's WS reaches the egress).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three findings, all valid:

- gofmt the imports in egress/quic.go. The earlier addition of `net`
  put it after `sync` instead of in stdlib alphabetical order, which
  gofmt now corrects.

- Fix t.Cleanup ordering in both migration tests. closeAllRecords was
  registered too early, which combined with t.Cleanup's LIFO
  semantics meant QUIC connections were being closed AFTER their
  underlying PacketConns. quic-go's read goroutines saw vanished
  transports before they saw the connection close, producing noisy
  error logs and an occasional race against the test assertion path.
  Move the closeAllRecords registration to AFTER the PacketConn
  registrations so it runs first in the cleanup order; comment the
  intent so future edits don't accidentally re-break it.

- Replace the hard-coded 4s upper bound and exact >=probeTimeout
  lower bound on the probe-timeout test with slack windows
  (probeTimeout - 100ms ≤ elapsed ≤ probeTimeout + 2s). This both
  avoids CI-scheduler-jitter flakes and keeps the test correct when
  probeTimeout is bumped — the explicit constant references the
  same probeTimeout the test sets on cm, so changing one updates
  both bounds.

3x test runs all stable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>