Rewrite README and Manual front pages in project voice

The repo front page read like generic documentation rather than a record of
why any of this exists. Adds the origin story, the current honest state, real
failure history, and fixes drift in platform_*() naming, the fallback tier
variable pattern, and the Plugin/unraid script locations.

Manual.md

@@ -3,11 +3,23 @@
 Getting a fresh two-server ecosystem running from scratch.  
 For system overview see [README.md](README.md). For individual subsystem detail see folder READMEs and script headers.
 
+**Ten steps, and they're in this order for a reason.** Each one assumes the previous one
+actually worked — not that you ran it, that it *worked*. Every step below ends with a way to
+check, and skipping those checks is how you end up three steps later debugging the wrong
+thing entirely.
+
+The steps that hurt most when rushed are **3** (naming) and **8** (testing failover). Step 3
+because renaming anything afterwards means chasing it through every conf, and step 8 because
+untested failover isn't redundancy — it's a guess you haven't checked yet.
+
+Budget an evening. It is not hard, but it is not five minutes either.
+
 ---
 
 ## ━━━ BEFORE YOU START ━━━
 
-Things that must be in place before you touch any scripts.
+None of this is optional and none of it is Varaverk's job to install. Get these in place
+first — every step after here assumes they're already true.
 
 ---
 
@@ -157,6 +169,21 @@ Replace these with your actual unRAID server hostnames. These must match exactly
 `detect_hosts()` compares the running server's hostname against these two values to
 know which server it is on. Everything else in the ecosystem flows from this.
 
+**Get this wrong and nothing works, but nothing errors either.** If neither value matches,
+`MY_ID` is never set, and every script that depends on it either exits early or resolves
+`${MY_ID}_SOMETHING` to an empty variable and quietly takes the wrong branch. Copy the value
+straight out of `hostname` on each box rather than typing what you think it is:
+
+```bash
+hostname     # run this on each server, paste the exact output
+```
+
+> **The 15-character trap.** unRAID truncates the Server Name to 15 characters for NetBIOS.
+> If your name is longer, what you set in the WebGUI and what `hostname` returns are two
+> different strings. `detect_hosts()` has a fallback that matches a truncated 15-char
+> hostname against a longer configured value — but only when the live hostname is
+> *exactly* 15 characters. Don't rely on it. Use the real `hostname` output.
+
 ---
 
 ### ── 3b. host1.conf — HOST1 identity ────────────────────────────────────────
@@ -206,15 +233,27 @@ HOST1_CRITICAL_SYNC_SHARES=(
     "/mnt/user/appdata-Fallback/Critical-Data|critical-data"
 )
 
-# Containers fallback.sh starts on HOST2 when HOST1 goes down (Tier 1 = immediate)
-HOST2_FALLBACK_HOST1_COVERS_HOST2_TIER1=()   # HOST2's own covers for HOST1, and vice versa
-HOST1_FALLBACK_HOST2_COVERS_HOST1_TIER1=(
+# Containers to start when HOST1 goes down (Tier 1 = immediate)
+# Lives in host1.conf. Named for the host being COVERED, not the host doing the covering.
+FALLBACK_HOST1_TIER1=(
     "Emby"
     "VaultWarden"
     "NginxProxyManager"
 )
 ```
 
+**Read that naming carefully — it catches people.** The variable is
+`FALLBACK_${REMOTE_ID}_TIER${N}`, and `REMOTE_ID` is *the host that went down*. So
+`FALLBACK_HOST1_TIER1` is the list HOST2 reads when HOST1 is unreachable. It defines
+"what HOST1 needs covering", not "what HOST2 runs".
+
+It lives in `host1.conf` for the same reason — HOST1 owns the description of its own
+service stack. HOST2 receives it through the conf cache rather than keeping its own
+opinion about what HOST1 runs. One list, one owner, no drift.
+
+Tiers 2–4 activate progressively after `HOST1_TIER2_DELAY` etc., so a brief outage never
+drags the entire remote stack across.
+
 For full configuration reference see `Manual-Fallback.md`, `Manual-Rsync.md`,
 and `Manual-Watchdogs.md`.
 
@@ -455,6 +494,18 @@ bash /boot/config/plugins/varaverk/Fallback/fallback_test.sh --log
 The test runs in phases — blocks HOST1's Tailscale IP, waits for `fallback.sh` to
 detect it and start Tier 1 containers, then unblocks and waits for handback.
 
+**Do not skip this step.** Everything up to here you can verify by reading output. Failover
+is the one part you cannot confirm by looking at it — a typo in a tier list, a container name
+that doesn't exist on the other side, a DDNS container that was renamed six months ago: all
+of it sits there looking completely fine until the moment it's needed.
+
+The test costs you twenty minutes and no downtime. The alternative is finding out at 2am,
+during the outage, when you have exactly one chance to get it right.
+
+**Watch the handback as closely as the failover.** Coming back is the harder half — it has to
+stop the remote's DDNS, sync the data back, start the local containers, and only then bring
+local DDNS up. Failover starting correctly tells you nothing about whether handback does.
+
 See [Manual-Fallback.md](Fallback/Manual-Fallback.md) for what each phase does and
 how to interpret the output.
 
@@ -651,6 +702,14 @@ Each subsystem has a README with the design decisions and a Manual with the conf
 reference and troubleshooting. The `--status` flag on any script shows the current
 configuration and state.
 
+**Turn things on one at a time and give each one a few days.** Everything below is off by
+default on a fresh install, and that's deliberate — a stack where six new subsystems went
+live the same night is a stack where you have no idea which one to blame. Enable, watch it
+through a full daily cycle, then enable the next.
+
+Anything that deletes files — the arr cleanup scripts especially — gets a `--dry-run --log`
+first. Read the list. Every time, not just the first time.
+
 ```
 Watchdogs/        → README-Watchdogs.md        configure memory limits, container lists
 Media/            → README-Media.md             enable arr cleanup, discovery scripts