Following the migration integration test (#359), the most likely
remaining cause of the prod "path probe error: context deadline
exceeded" failures we've been seeing on the egress is consumer-side
QUIC connection-state GC during the WebRTC re-pair gap. We can't
distinguish that from other QUIC failure modes today because the
consumer-side log of every connection death is the same:

  "QUIC connection error (<err>), closing!"

This change replaces the freeform error log with a structured slog
record that adds err_class and lifetime_s fields:

  "QUIC connection ended"
    err=...
    err_class=idle_timeout|application_close|transport_error|...
    lifetime_s=42.3

Doing it this way means we don't have to read individual error
strings to count failure modes — grep on err_class and we're done.

Specifically:
- err_class=idle_timeout combined with lifetime_s ≈ MaxIdleTimeout is
  the smoking-gun signature for "consumer GC'd during re-pair gap".
  If we see this dominate the failure mix, bumping MaxIdleTimeout
  (currently 60s) and/or shortening KeepAlivePeriod (currently 15s)
  is a cheap structural fix.
- err_class=application_close is normal teardown when the egress's
  migrationWindow expires.
- err_class=context_canceled is local Close().
- err_class=transport_error / stateless_reset / version_negotiation
  point at quic-go-internal failures.

Also adds the same err_class field to the existing listener.Accept
error log, since that path can also fail with the same set of error
types.

Tests cover all eight known classifications via type-asserted
constructors plus wrapped/nil/plain-error baselines. quic-go's error
types are exported as of v0.59 so we don't need any reflection
gymnastics.

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

Address Copilot review on #360: quic.ApplicationError carries a
Remote flag indicating whether the close was peer-initiated or
local-initiated. Lumping both into the same "application_close" tag
hid the distinction between "egress finished its migrationWindow and
flushed the record" (remote, expected normal teardown) and "the
local QUICLayer closed its own connection mid-flight" (local,
suspicious enough to want flagged separately).

Split into application_close_remote and application_close_local. Doc
comment + the inline classifier comment now describe both. Tests
construct the ApplicationError both with Remote=true and Remote=false
(plus the wrapped-error variants) to lock in the routing.

In production the consumer's QUICLayer doesn't currently call
CloseWithError on the connection except as cleanup AFTER AcceptStream
errors, so we expect application_close_local to be near-zero. If it
shows up, that's a signal worth investigating separately rather than
ignoring under the "egress closed us" assumption.

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