quic: expose an API for client connection migration

Start by reviewing RFC 9000's connection migration section, the ngtcp2_conn_initiate_migration() declaration in the linked ngtcp2 header, and the earlier Node.js QuicClientSession.migrate() API. Compare these with the prototype linked in manNomi/node#5; the work is done when the Node.js public API shape and migration behavior are agreed and specified.

What is the problem this feature will solve?

The current experimental node:quic API does not expose a way for a client to
intentionally move an established QuicSession to another local
QuicEndpoint. This is useful when an application wants to move a connection
between network interfaces or local UDP ports while preserving the existing
QUIC session, streams, and datagram flows.

Reconnecting is not equivalent because it discards the existing session state
and requires another handshake. Passive NAT rebinding also does not let an
application explicitly select a new local socket or interface.

RFC 9000 defines client-initiated connection migration. The
current API already exposes QuicEndpoint, session.path, and
session.onpathvalidation, and the bundled ngtcp2 implementation provides
ngtcp2_conn_initiate_migration(). The earlier experimental
Node.js QUIC API also exposed
QuicClientSession.migrate(quicSocket).

Would the QUIC team be interested in exposing this capability in the current
API?

What is the feature you are proposing to solve the problem?

One possible high-level API would be:

await session.migrate(endpoint);

The proposed behavior would be:

• It is available only for client sessions after the handshake is confirmed.
• An unbound target endpoint is bound before path validation begins.
• It rejects if the peer advertised disable_active_migration or if validation
  of the new path fails.
• It resolves after the new path has been validated and selected as the active
  path.
• Existing streams and datagram flows remain attached to the same session, and
  session.path reflects the new active path.

There are two related API questions where feedback would be useful:

1. Should Node.js expose one high-level migrate(endpoint) operation, or a
   lower-level path abstraction that separates probing from switching?
2. Should server transport parameters expose a disableActiveMigration option
   for deployments that cannot preserve connection routing when a client's
   address changes?

I have explored a proof of concept in manNomi/node#5, but I would
like to agree on the public API shape before opening an upstream pull request.

What alternatives have you considered?

One alternative is to expose a path-oriented API similar to quic-go:

const path = session.addPath(endpoint);
await path.probe();
path.switch();
path.close();

This gives applications control over when a candidate path is validated and
when it becomes active, but adds another public abstraction and more lifecycle
management.

Applications can instead create a new QUIC session or rely on OS routing and
passive NAT rebinding. Neither option provides explicit migration to a chosen
local endpoint while preserving the existing session and its streams.