docs: capture Serenity majority migration plan

docs/planning/SERENITY_DOCKER_AUDIT.md

@@ -30,7 +30,6 @@ These are the containers whose current placement still makes operational sense b
 - `bazarr`
 - `autobrr`
 - `unpackerr`
-- `Notifiarr`
 - `shelfmark`
 
 Common pattern observed from live mounts:
@@ -53,14 +52,17 @@ These are live today, but they are not good long-term reasons to keep Serenity a
   - live on Serenity now
   - operator confirmed it is still needed, so it should be preserved during cleanup and only rehomed deliberately later
 - `Hawser`
-  - helper/observability tooling, not a reason to preserve Serenity as a host role
+  - operator confirmed Dockhand depends on it for remote management of Serenity's remaining Docker stacks
+  - keep on Serenity with `dockersocket` until that management pattern is intentionally replaced
 - `dockersocket`
-  - Hawser helper sidecar only; keep or move with Hawser rather than treating it as a standalone host role
+  - Hawser helper sidecar required by the current Dockhand remote-management path
 - `netdata`
   - useful while Serenity remains live, not a reason to keep Serenity permanently
+- `Notifiarr`
+  - low-risk utility app that can move later if PD has spare headroom
+  - not urgent while PD remains RAM-constrained
 - `Wizarr`
-  - this is a normal app workload, not a storage-appliance-only workload
-  - long-term candidate for PD well before any final Serenity storage retirement if you want to peel off low-risk miscellaneous apps early
+  - operator confirmed it is unused and should be retired rather than migrated
 
 ### Placement verdict by service group
 
@@ -88,15 +90,14 @@ Reason:
 - all of these either mount Serenity-owned `/mnt/user/data` directly or depend on the downloader/media-path locality that still lives on Serenity today
 - moving them before PD owns the storage locally would just trade one cleanup project for a fragile NFS-path rewrite project
 
-#### Move off Serenity whenever the destination design is ready
-- `Wizarr`
-- `Hawser`
-- `dockersocket`
-- `netdata`
+#### Optional early cleanup / peel-off work
+- retire `Wizarr`
+- move `Notifiarr` only if PD headroom clearly allows it
+- review whether `netdata` still adds enough local-monitoring value to keep
 
 Reason:
-- these are not durable storage-owner roles
-- they can move independently of the qbit/ARR locality lane once you decide whether PD should absorb them or whether one of them is no longer worth keeping
+- these are the few remaining low-risk app-level changes that do not depend on the qbit/ARR storage cutover
+- PD is constrained right now, so only very small wins should happen before the larger storage redesign
 
 #### Keep as explicit temporary exceptions, then redesign last
 - `reranker`
@@ -184,8 +185,8 @@ Notable typo/risk:
 - current live work should start from the narrower remaining set, not re-open that cleanup unless new evidence appears
 
 ### Phase 2: peel off the low-risk non-locality apps
-- move `Wizarr` to PD when convenient
-- move or retire `Hawser` + `dockersocket`
+- retire `Wizarr`
+- optionally move `Notifiarr` if PD headroom clearly permits it
 - decide whether `netdata` still provides unique value once the broader monitoring stack is considered
 
 ### Phase 3: preserve the only things that currently justify Serenity
@@ -216,8 +217,8 @@ Once PD directly owns the relevant media/torrent datasets:
 - treat ad-hoc Unraid container definitions as a drift risk until they are intentionally replaced
 
 ### Epic B — low-risk miscellaneous app peel-off
-- move `Wizarr` to PD or retire it
-- decide whether `Hawser` + `dockersocket` should move as a pair or just disappear
+- retire `Wizarr`
+- decide whether `Notifiarr` is worth an early move given PD RAM pressure
 - decide whether `netdata` still earns its keep alongside the broader monitoring stack
 
 ### Epic C — torrent/media-locality preservation until PD cutover
@@ -247,7 +248,7 @@ Resolved on 2026-05-25:
    - move qbit + ARR family to PD after storage cutover
    - leave no intentional production app role on Serenity
    - retire Serenity entirely
-6. `Wizarr`, `Hawser`/`dockersocket`, and probably `netdata` are explicitly low-risk move/retire candidates that do not need to wait for the storage cutover.
+6. `Wizarr` is explicit retire-now dead weight; `Notifiarr` is the main optional tiny move candidate; `Hawser`/`dockersocket` remain intentional keepers because Dockhand depends on them.
 
 ## Remaining verification questions