Enhanced authentication does not enforce Authentication Method continuity

Description

The client supports MQTT 5 enhanced authentication but does not validate that the Authentication Method remains identical to the method sent in CONNECT.

During the initial exchange, connect_enhanced_auth retains the configured method for its own outgoing packets, but accepts incoming AUTH and successful CONNACK packets without comparing their Authentication Method to it:

https://github.com/microsoft/rust-mqtt-client/blob/e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d/src/client.rs#L657-L714

https://github.com/microsoft/rust-mqtt-client/blob/e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d/src/client.rs#L930-L968

During post-connect re-authentication, Session::incoming_auth instead copies the method supplied by the server into ReauthToken:

https://github.com/microsoft/rust-mqtt-client/blob/e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d/src/client/session.rs#L584-L606

continue_reauth then sends that peer-supplied method back, allowing a server to switch the exchange to a different method:

https://github.com/microsoft/rust-mqtt-client/blob/e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d/src/client/token/reauth.rs#L44-L69

Reproduction

Initial authentication:

1. Call connect_enhanced_auth with Authentication Method method-a.
2. Have the server send AUTH with reason Continue Authentication and Authentication Method method-b, or send a successful CONNACK with a missing/different method.
3. The client reports Continue/Success instead of a protocol failure.

Re-authentication:

1. Establish a connection using method-a and initiate re-authentication.
2. Have the server reply with Continue Authentication using method-b.
3. Continue through the returned token; the client sends method-b back.

Expected behavior

Retain the Authentication Method established by CONNECT for the lifetime of the network connection. Every incoming AUTH and every successful CONNACK in the initial exchange must contain that exact method. Missing or mismatched methods must be treated as a Protocol Error rather than accepted or echoed.

MQTT 5.0 requirements:

• [MQTT-4.12.0-5]: when CONNECT contains an Authentication Method, all AUTH packets and any successful CONNACK must contain the same value.
• [MQTT-4.12.0-6]: when CONNECT omits it, the server must not send AUTH or an Authentication Method in CONNACK.
• [MQTT-4.12.1-1]: re-authentication must use the method originally used for the network connection.

Specification: https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html

Audited revision

e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d

Start with connect_enhanced_auth in src/client.rs, then inspect Session::incoming_auth in src/client/session.rs and continue_reauth in src/client/token/reauth.rs. Compare incoming AUTH and successful CONNACK methods with the CONNECT method, including missing values, and verify re-authentication retains the original method and treats violations as protocol errors.