docs(plan): tick Phase 10.5 — ApplyStoragePools non-stub landed

Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Author: kvaps

PLAN.md

@@ -707,7 +707,7 @@ on the affected clusters.
 
 ### 10.5 — `ApplyStoragePools` made non-stub (absorbs the existing architectural-debt item)
 
-- [ ] Today the satellite's `Provider` registry is seeded by CLI flags (`--lvm-thick-pool-name=…`, `--zfs-pool=…`, etc.) at startup, and `ApplyStoragePools` is an Ok=true stub. After 10.5 the controller pushes desired pool config via the existing `StoragePool` CRDs (which carry `ProviderKind`, `Props`, etc.); satellite's StoragePool reconciler watches own pools (`Spec.NodeName == self`), instantiates the matching `storage.Provider` dynamically with the configured VG / pool / dir / mountpoint, registers in its in-memory map. Pool capacity reporting flips to a satellite-side periodic write to `StoragePool.Status` (already on the type).
+- [x] ApplyStoragePools dynamic provider registration (2026-05-10). `pkg/satellite/factory.go.NewProviderFromKind` switches on `provider_kind` and reads `StorDriver/<key>` props to instantiate LVM thick/thin / ZFS / FILE / LOOPFILE providers; `Reconciler.RegisterProvider` adds them to the in-memory map under mutex. Per-pool failure surfaces via `StoragePoolApplyResult.Ok=false`+Message without sinking the batch. Pinned via `TestGRPCServerApplyStoragePoolsRegistersValid` covering LVM_THIN+ZFS happy paths and both failure modes (unknown kind, missing required prop). The full StoragePool-CRD-watch path (satellite-as-controller-runtime, capacity write to Status) lands once Phase 10.1 retires the gRPC contract.
 - [ ] Drop the `--lvm-thick-pool-name` / `--lvm-thick-vg` / `--zfs-pool` / `--lvm-thin-vg` / `--lvm-thin-pool` / `--file-pool-dir` / `--loopfile-pool-dir` flags from `cmd/satellite/main.go`. Adding a new pool becomes `kubectl apply -f storagepool.yaml`, no DaemonSet rollout.
 
 ### 10.6 — Remove the gRPC contract entirely