docs(reference): import Dune: Awakening server-manager references

Phase 2 references for the host-agent Dune adapter, moved out of volatile /tmp
into docs/reference-repos/ (per Commander). Three upstream projects, .git +
node_modules + compiled binaries stripped (16MB source). Nested AI-instruction
files (.claude/, CLAUDE.md) removed so they don't pollute Corrosion sessions.

- icehunter/    dune-admin (Go+React) — 4 control planes; SETUP_DOCKER.md is the
                closest analog to our agent's Dune docker control plane (compose
                lifecycle, docker logs, RabbitMQ-via-exec, dune Postgres schema)
- adainrivers/  Rust/Tauri desktop — SSH+k8s BattleGroup control, maintenance
                daemon, in-game admin console (Rust idiom reference)
- the4rchangel/ Node web UI replacing battlegroup.bat — matches the Commander's
                Hyper-V self-host path + game-config schema

See docs/reference-repos/README.md for the full index + how we use each.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/reference-repos/adainrivers/release-notes/0.3.16.md

@@ -0,0 +1,17 @@
+# 0.3.16
+
+This release fixes two BattleGroup control problems: scheduled restarts that wrongly reported a failure even though the server came back online fine, and the Stop / Start / Restart buttons misbehaving after a Funcom server update.
+
+## Reinstall step
+
+The scheduled-restart fix lives in the host service. After updating the desktop app, open each server's **Management Service** card and click **Install / Update** so the refreshed host service is pushed. The Stop / Start / Restart button fix takes effect as soon as the desktop app itself is updated.
+
+## Fixed
+
+- **Scheduled restarts no longer report a false failure (#20).** A nightly restart could log a "restart failed: timeout after 1200s" error roughly 20 minutes later even though the BattleGroup and all map servers were actually back online within a few minutes. The readiness check insisted on a fully settled state and refused to accept a BattleGroup that was up but still showing as `Reconciling` (a state in which the servers are already reachable), so it waited out the full timeout and reported a failure that never happened. It now recognises a reachable, started BattleGroup the same way the dashboard does, so a successful restart is reported as success.
+
+- **Stop / Start / Restart BattleGroup work again (#19).** After a Funcom server update, the **Stop BattleGroup** button could fail with a "battlegroup status can not be pulled" error while the server kept running, even though stopping over SSH worked fine; Start and Restart could also stall until their timeout. The cause was that these actions read the vendor `battlegroup status` text output, whose column layout shifts between Funcom releases and was being misread. They now read BattleGroup state directly from the stable Kubernetes data the dashboard already uses, so they no longer break when the vendor output format changes.
+
+## Notes
+
+- No configuration changes are required. Existing schedules, welcome packages, and enable switches keep their current settings.