refactor(runtime): delete the dead in-place ApplyDelta seam; config change = respawn only (#665)

Since #516 a DriverConfig change is stop + respawn, so DriverSpawnPlan.ToApplyDelta
was always empty and the in-place path had no producer. #663 and #664 were both
latent bugs in it. This deletes it:
- host: ApplyChildDelta, _pendingDelta, HandleApplyResult and HandleDeltaApplied
- plan: DriverSpawnPlan.ToApplyDelta
- actor: the ApplyDelta, ApplyResult and DeltaApplied messages, the Connected
  reinit handler and the mid-connect AdoptConfigDuringInit
- tests: the actor tests that drove the seam

IDriver.ReinitializeAsync and each driver's implementation and unit tests stay.
Comments and docs that cited AdoptConfigDuringInit as the reason a driver must
release prior state at init now cite the IDriver contract and overlapping
retries, which still apply.

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

docs/drivers/Mqtt.md

@@ -415,7 +415,7 @@ down rather than swallowing it. A SUBACK failure degrades just the affected RawP
 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
+comms-loss watchdog's retry path, and a `ReinitializeAsync` 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