send WebSocketConfig headers, subprotocols and user agent in the upgrade request (#165)

CHANGELOG.md

@@ -5,6 +5,31 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+### Fixed
+
+- **The WebSocket client transport now sends its configured headers, subprotocols and user agent** (#165). `WebSocketTransport::connect` built the upgrade request from a fixed set of headers and always offered `Sec-WebSocket-Protocol: mqtt`, so anything set with `WebSocketConfig::with_header`, `with_subprotocol`, `with_subprotocols` or `with_user_agent` never reached the server, and brokers that authenticate the upgrade request through custom headers rejected the connection. The request now carries every custom header, the configured subprotocols in order, followed by `mqtt` when the list does not include it (MQTT-6.0.0-3), and the user agent when one is set. The default user agent is now `mqtt5/<crate version>` instead of `mqtt-v5/0.4.0`.
+- **The upgrade request's `Host` header now includes a non-default port**, so `ws://broker:8080/mqtt` sends `Host: broker:8080` rather than `Host: broker`.
+
+### Changed
+
+- **WebSocket configurations that relied on the old behavior may connect differently or fail to connect.** Because the configuration now reaches the wire:
+  - A custom header that is invalid or reserved (see the next entry) used to be silently dropped. It now makes `connect` fail.
+  - Every WebSocket connection, including those made by `MqttClient`, now sends a `User-Agent` header.
+- **`connect` rejects a WebSocket configuration it cannot send faithfully, before dialing.** It fails with `MqttError::Configuration` in these cases:
+  - a custom header has an invalid name or value, or repeats another custom header's name (case-insensitively);
+  - a custom header names one reserved for the handshake: `Host`, `Connection`, `Upgrade`, `Sec-WebSocket-Version`, `Sec-WebSocket-Key`, `Sec-WebSocket-Extensions` or `Sec-WebSocket-Accept`;
+  - a custom header is `Content-Length`, `Transfer-Encoding` or `Trailer`, which would describe a body the upgrade request does not have, or a hop-by-hop or expectation header: `TE`, `Keep-Alive`, `Proxy-Connection` or `Expect`;
+  - `Sec-WebSocket-Protocol` or `User-Agent` is set as a custom header instead of through its setter;
+  - a subprotocol is not a valid HTTP token, or is listed more than once (RFC 6455 §4.1).
+- Custom headers are sent, and validated, in name order, so the request and the error a bad configuration reports no longer depend on `HashMap` iteration order.
+- `WebSocketConfig`'s `Debug` output lists custom header names but not their values, which often carry credentials.
+
+### Added
+
+- `WebSocketConfig::build_handshake_request`, which returns the upgrade request the configuration produces.
+
 ## [mqtt5 0.47.3] - 2026-10-09
 
 ### Fixed