docs: record Serenity cleanup decisions

docs/planning/SERENITY_DOCKER_AUDIT.md

@@ -50,8 +50,8 @@ These are live today, but they are not good long-term reasons to keep Serenity a
   - current backup Technitium node on Serenity (`10.5.30.10`)
   - long-term: keep at least one off-PD backup resolver, but that does not have to remain on Serenity forever
 - `Newt`
-  - live on Serenity now, but docs only call out PD and NOMAD as the intended long-term Pangolin/Newt exposure lane
-  - verify whether this agent is still needed before keeping it
+  - 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
 - `netdata`
@@ -74,7 +74,7 @@ These should be treated as cleanup targets unless a specific live dependency is
 - `keepalived-pihole-serenity`
   - these are legacy DNS/HA remnants now that Technitium is the active resolver strategy
   - repo docs now describe the Technitium trio as the active DHCP-advertised internal DNS path
-  - unless some forgotten client or admin workflow still depends on them, these should be drained and removed
+  - operator confirmed Technitium covers the intended DNS role, so these should be treated as removable at the next cleanup window
 - `postgresql15`
 - `MariaDB-Official`
   - both are live, but they are suspicious because current docs position PD as the shared database home
@@ -190,22 +190,45 @@ Once PD directly owns the relevant media/torrent datasets:
 - preserve only the intended backup-DNS failure-domain role off PD
 - decommission Serenity once no production path depends on it
 
-## Approval questions
+## Resolved operator decisions
 
-1. Do you want to keep any of these as deliberate long-term Serenity residents, even after PD takes storage ownership?
-   - GameVault
-   - RomM
-   - Wizarr
-   - Shelfmark
-   - Notifiarr
+Resolved on 2026-05-25:
 
-2. Is the legacy Pi-hole stack on Serenity allowed to be removed once we confirm Technitium covers all intended DNS duties?
-
-3. Should Newt on Serenity be treated as a real long-term exposure path, or as cleanup unless we prove it is needed?
-
-4. Are GameVault / RomM considered "nice to keep somewhere" apps that should migrate to PD, or are they candidates to prune?
-
-5. Once PD owns the disks locally, is your preferred policy still:
-   - move qbit + ARR family to PD
+1. No app should deliberately remain on Serenity once PD owns the disks locally.
+2. Technitium covers the desired DNS role; the legacy Serenity Pi-hole stack should be treated as removable.
+3. `Newt` on Serenity is still needed and should not be treated as cleanup.
+4. `GameVault` and `RomM` should migrate rather than be pruned.
+5. End-state remains:
+   - move qbit + ARR family to PD after storage cutover
    - leave no intentional production app role on Serenity
    - retire Serenity entirely
+
+## Remaining verification questions
+
+- Confirm whether anything beyond `GameVault` still depends on `postgresql15`.
+- Confirm whether anything beyond `RomM` still depends on `MariaDB-Official`.
+- Is `/mnt/user/appdate/reranker` intentional, or a typo that should be corrected before migration?
+
+## Database dependency findings
+
+Live inspection of container environments currently points to:
+
+- `GameVault` -> local `postgresql15`
+  - `DB_HOST=10.5.30.5`
+  - `DB_PORT=5432`
+- `RomM` -> local `MariaDB-Official`
+  - `DB_HOST=10.5.30.5`
+  - `DB_PORT=3306`
+
+No immediate database dependency was surfaced from the quick live environment check for:
+
+- `Wizarr`
+- `Shelfmark`
+- `Notifiarr`
+
+Operational implication:
+
+- `postgresql15` should currently be treated as a `GameVault` dependency until proven otherwise.
+- `MariaDB-Official` should currently be treated as a `RomM` dependency until proven otherwise.
+- those databases can likely retire once their dependent apps are migrated to PD and verified there.
+- the legacy Pi-hole containers can be scheduled for removal at the next cleanup window.