upgrade mqtt5 to 0.45.1

[fabracht]

Summary

• Upgrade mqtt5 from 0.39.2 to 0.45.1 (mqtt5-protocol 0.15.0 to 0.15.2). No MQDB source changes were needed.
• Agent mode's <db>/mqtt_storage migrates to storage format 2 on first start, and older builds refuse it. Users must back up the directory before upgrading; the CHANGELOG says so.
• MQDB's 1-hour session expiry is now enforced as the maximum the broker grants. A v5 CONNECT without a Session Expiry Interval now ends its session at disconnect.
• Version bumps: agent 0.8.30, cluster 0.4.16, vault 0.1.6, cli 0.8.40. hold-reclaim.md is updated for 0.45; its claims about mqtt5's connect/disconnect event order were re-checked against the 0.45.1 source.
• The CHANGELOG entry also adds the missing entries for fix quic partial-frame desync via per-peer writer task #145, split quic peer sends into control and bulk priority lanes #147, redial disconnected cluster peers and remove dead ones #148, speed up and harden cluster peer redial #150, make replicated subscriptions authoritative in subscription reconcile #151 and default dev clusters to a full peer mesh and wait for a settled partition map #156, which ship in the same release, plus make replicated subscriptions authoritative in subscription reconcile #151's mqdb-cluster API change.
• Rebased onto default dev clusters to a full peer mesh and wait for a settled partition map #156, which now carries the dev-test settle wait this PR originally had.
• Not fixed here: ClientConnectEvent.clean_start now reports whether a session was resumed, so a client's first connect with Clean Start 0 still reads as clean. Moving cluster disconnect cleanup to the granted session expiry is a follow-up PR.

Test plan

• cargo make clippy
• cargo make test
• Agent upgrade from a 0.39.2 data directory: the storage version goes from 1 to 2, a record created before the upgrade reads back, a persistent session resumes and receives the message queued while it was offline, and the 0.39.2 build then refuses the migrated directory.
• 5-node mqdb dev test on the rebased branch (full-mesh dev clusters from default dev clusters to a full peer mesh and wait for a settled partition map #156): ownership 5/5, sharing 5/5, presence 3/3, and --all 2/2 with every sub-suite passing. The partition map settled in 4.7–6.7 s each time.
• The constraints sub-suite passed both runs here, but it is timing-dependent (a create right after constraint add can get a retryable 503 for several seconds), so this is not counted as fixed.