fix(mqtt): session-rebind subscriptions, re-init teardown, timeout clamp

Findings from the per-module review of Driver.Mqtt at b990adae
(code-reviews/Driver.Mqtt/findings.md records all ten; these are the fixed
ones).

Driver.Mqtt-001 (High) — MqttSubscriptionManager._subscribedTopics is a claim
about the broker session it established filters on, and AttachTo never cleared
it, but the manager OUTLIVES a session rebuild (AdoptOptions keeps it whenever
the ingest identity is unchanged). After a driver-host reconnect
(ShutdownAsync + InitializeAsync, the #527 watchdog's retry) or a
ReinitializeAsync that only changed the endpoint/credentials, the host's
re-subscribe resolved an empty pending set, sent no SUBSCRIBE at all, and left
the driver Connected/Healthy on a session carrying ZERO subscriptions — no
error, no Bad status, values frozen until the new session happened to drop.
AttachTo now forgets them, mirroring SparkplugIngestor.AttachTo's reset.

Driver.Mqtt-002 (High) — InitializeCoreAsync published _connection and
_primaryHost over whatever the driver already held, so a second initialize
stranded a connected, self-supervising broker session (plus a second Sparkplug
primary-host claim) that no later dispose could reach. Reachable without any
teardown of ours via DriverInstanceActor.AdoptConfigDuringInit. Now tears down
first, under the gate both callers already hold.

Driver.Mqtt-003 (Medium) — connectTimeoutSeconds is [Range]-annotated but
unvalidated on the runtime path; 0 makes every deadline fire immediately and a
negative value throws ArgumentOutOfRangeException out of ShutdownAsync and
DisposeAsync. Normalized once, at the seam every options instance passes.

Also: ShutdownAsync keeps the live last-message instant (-004), three usings
left behind by #512 removed (-005), stale remarks corrected (-009, -010), and
docs/drivers/Mqtt.md now distinguishes the two kinds of reconnect.

Tests 708 -> 713. All three regression tests were confirmed to fail against
the un-fixed code, with two controls that pass in either state.

docs/drivers/Mqtt.md

@@ -404,6 +404,17 @@ nothing forever, so `OnReconnectedAsync` **throws** when zero filters are grante
 down rather than swallowing it. A SUBACK failure degrades just the affected RawPaths to
 `BadCommunicationError`.
 
+There are **two** kinds of reconnect and only one of them fires that callback. A drop the connection's
+own supervisor recovers keeps the same `MqttConnection`, so `Reconnected` → `OnReconnectedAsync`
+re-establishes every live filter. A **session rebuild** — `ShutdownAsync` + `InitializeAsync` (the #527
+comms-loss watchdog's retry path, and an `ApplyDelta` that changes the endpoint or credentials) — builds
+a *new* connection and re-attaches the *same* `MqttSubscriptionManager`, and the re-subscribe then comes
+from the host (`DriverInstanceActor.ResubscribeDesired`) rather than from the callback. `AttachTo`
+therefore **forgets the filters the previous session had established**: the dedupe set is a claim about
+one session, and carrying it across made the host's re-subscribe resolve an empty pending set, send no
+SUBSCRIBE at all, and leave the driver Connected/Healthy and permanently deaf. Sparkplug's
+`SparkplugIngestor.AttachTo` resets its own session state for the same reason.
+
 ## Write-through
 
 `IWritable` landed with [#508](https://gitea.dohertylan.com/dohertj2/lmxopcua/issues/508). Before it,