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

src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy/GalaxyDriver.cs

@@ -349,8 +349,8 @@ public sealed class GalaxyDriver
 
     /// <inheritdoc />
     /// <remarks>
-    ///     #664: <c>InitializeAsync</c> is reachable on a live driver with a NEW config —
-    ///     <c>DriverInstanceActor.AdoptConfigDuringInit</c> re-runs it when an ApplyDelta lands mid-connect. The
+    ///     #664: <c>InitializeAsync</c> takes a config document, and the <see cref="IDriver"/> contract is that a
+    ///     driver serves the one it is handed (the runtime's own mid-connect adoption path was deleted in #665). The
     ///     driver cannot hot-swap its options (they shape the gw session; see <see cref="ReinitializeAsync"/>), so a
     ///     non-equivalent config with a real body is REFUSED here too rather than silently ignored — the driver
     ///     would otherwise connect on its old endpoint while the deploy reported the change applied. A