bound the client offline queue and close remaining publish outcome gaps

[fabracht]

Follow-ups from the publish-outcome work in #164 (PublishResult::Queued, PublishHandle, TLA+ model in specs/tla/offline-queue/). None of these is a conformance violation.

1. Offline queue has no configurable bound. It is limited only by the packet-id space (65535 queued QoS 1/2 messages), and every entry holds its full payload, so memory is effectively unbounded for large payloads. Add a configurable limit (count and/or bytes) with a documented overflow policy. Rejecting at publish() with a clear error fits the outcome model better than dropping silently.
2. QoS 2 packet-id quarantine is not persisted. An abandoned QoS 2 id is quarantined in memory until a Session Present=0 connection. After a process restart that resumes the broker session with resume_existing_session, the quarantine is gone, and a new QoS 2 publish can reuse an id the broker still holds (it would be treated as a duplicate). Persist it with the session state, or document the limitation.
3. Offline-queued publishes skip the codec registry and OpenTelemetry trace injection. The live path applies both; the queued path builds the packet without them.
4. Cancelling a live publish() future leaks a quota slot. If the future is dropped after it claimed send quota but before the message was stored, one Receive Maximum slot stays taken until the next reconnect.

[fabracht]

All four items are done.

1. Offline queue bound: bound the client offline queue #199, released in 0.46.0. The queue now enforces session_config.max_queued_messages (default 1000) and max_queued_size (default 64 MiB). A publish over either limit fails with MqttError::OfflineQueueFull.
2. QoS 2 id quarantine across a restart: not persisting it. I tested the scenario in correct resume_existing_session delivery docs #200. A client leaves a QoS 2 exchange at PUBREC, then a fresh process resumes the session and publishes QoS 2 with the same packet id. Our broker and Mosquitto 2.1.2 both treat the new publish as replacing the held one and deliver it, so the duplicate drop described above doesn't happen on either. What the test did turn up is that the unfinished publish itself is never delivered, while the resume_existing_session docs promised at-least-once across a restart. The docs are corrected in 0.46.1.
3. Codec and trace context on queued publishes: apply the codec and trace context to publishes queued while offline #198, released in 0.45.3.
4. Quota slot leak on a cancelled publish: return the receive maximum slot when a publish is cancelled #197, released in 0.45.2.

If you want to check item 2 yourself, run cargo test -p mqtt5 --test qos2_resume_after_restart. To try another broker, replace broker.address() in payloads_after_restart with that broker's address and see whether the publish after the restart arrives.