doc audit — fix stale watchdog vars, fallback_state_reset, add monthly_maintenance and mesh_monitor sections

- Tools/Manual-Tools.md: fallback_state_reset.sh marked not yet built; manual
  workaround added; TOC entry updated; failover→fallback rename throughout
- Watchdogs/Manual-Watchdogs.md: System Watchdog config block updated — remove
  pre-split vars (MEM_WARN_GB, MEM_SHUTDOWN_GB, MEM_GB, MEM_RECOVER_GB,
  SYS_WATCHDOG_MEM_SHUTDOWN_EXCLUDED, SYS_WATCHDOG_REQUIRED_CONTAINERS);
  add SYS_WATCHDOG_MEM_GB (reboot trigger only); fix state file path names
  (watchdog_state.db → container_watchdog_state.db,
  sys_watchdog_state.db → system_watchdog_state.db)
- Orchestrators/README-Orchestrators.md: add monthly_maintenance.sh section
  with two-gate model, configuration reference, and usage examples
- Monitors/README-Monitors.md: add mesh_monitor.sh to both tables and diagram
- Monitors/Manual-Monitors.md: add mesh_monitor.sh section
- README-User_Script_Plug-in.md, Rsync/README-Rsync.md, Rsync/Manual-Rsync.md,
  README.md: emby-failover → emby-fallback (missed from prior batch)

Tools/Manual-Tools.md

@@ -11,7 +11,7 @@ making any changes.
 - [emby_to_lidarr_sync.sh](#emby_to_lidarr_syncsh)
 - [emby_to_sonarr_sync.sh](#emby_to_sonarr_syncsh)
 - [emby_to_radarr_sync.sh](#emby_to_radarr_syncsh)
-- [failover_state_reset.sh](#failover_state_resetsh)
+- [fallback_state_reset.sh](#fallback_state_resetsh) *(not yet built — manual workaround)*
 - [watchdog_skip_list_manager.sh](#watchdog_skip_list_managersh)
 - [bulk_permissions_repair.sh](#bulk_permissions_repairsh)
 - [container_data_export.sh](#container_data_exportsh)
@@ -141,15 +141,17 @@ bash Tools/emby_to_radarr_sync.sh
 
 ---
 
-## failover_state_reset.sh
+## fallback_state_reset.sh
 
-Resets the fallback state file to NORMAL and clears all tier flags. State file only —
-does NOT start or stop any containers.
+> **Not yet built.** Use the manual workaround below.
+
+Planned: reset the fallback state file to NORMAL and clear all tier flags. State file
+only — does NOT start or stop any containers.
 
 ### When to Use
 
 ```
-After failover_test.sh didn't complete cleanly
+After fallback_test.sh didn't complete cleanly
   → state left in FALLBACK but containers are actually back to normal
 
 After a failed handback
@@ -162,13 +164,13 @@ After a dev/debug session
   → state left in a non-NORMAL state from testing
 ```
 
-### Verify Before Resetting
-
-Run `--status` first and check each of these before writing:
+### Manual Workaround
 
 ```bash
+# Verify before resetting:
+
 # Right containers on right server?
-continuous_scripts_status.sh        # shows failover current state
+continuous_scripts_status.sh        # shows fallback current state
 
 # DDNS pointing correctly?
 nslookup Gmer4Lfe.com               # confirm it resolves to the right IP
@@ -178,24 +180,20 @@ pgrep -f "fallback.sh"              # empty output = not running
 
 # Both servers Tailscale connected?
 tailscale status                    # both hosts should show active
+
+# Check current state file:
+cat /boot/config/fallback_state.db
+
+# Reset to NORMAL (only after confirming containers and DDNS are correct):
+echo "state=NORMAL" > /boot/config/fallback_state.db
 ```
 
-Resetting during an actual failover causes fallback.sh to think everything is normal
+Resetting during an actual fallback causes fallback.sh to think everything is normal
 and stop covering the remote — services go offline until the next detection cycle.
 
-### Usage
+### What the State File Contains
 
 ```bash
-fallback_state_reset.sh --status     # show current state file — always check first
-fallback_state_reset.sh --dry-run    # show what would be written, no write
-fallback_state_reset.sh              # interactive reset — prompts for YES to confirm
-fallback_state_reset.sh --force      # non-interactive — for scripts, no terminal
-```
-
-### What Gets Written
-
-```bash
-# New state file after reset:
 state=NORMAL
 fallback_start=0
 handback_strikes=0