quic: expose an API for client connection migration

### 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][rfc-migration]. The current API already exposes `QuicEndpoint`, `session.path`, and `session.onpathvalidation`, and the bundled ngtcp2 implementation provides [`ngtcp2_conn_initiate_migration()`][ngtcp2-migration]. The earlier experimental Node.js QUIC API also exposed [`QuicClientSession.migrate(quicSocket)`][old-node-quic]. 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: ```js 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`…