Storage-mode awareness pass + doc update for System_Essentials through Partnership

All state/data file paths in scripts and PHP now resolve via STATE_DIR / DATA_DIR /
PERSISTENT_CONF_CACHE instead of hardcoded /boot/config/ or /tmp/ paths, so the
ecosystem works in both internal and appdata storage modes.

PHP layer (watchdog.php, partnership.php, fallback.php, monitor.php, snapshot.php,
config.php): all state reads switched to STATE_DIR constant; remote state reads use
the new vv_remote_state_cmd() helper which resolves the remote's SCRIPTS_DIR via
their varaverk.cfg before building the path.

conf_sync.sh: fixed SCRIPTS_ROOT → SCRIPTS_DIR bug on MY_CONF path; added
_remote_scripts_dir() to resolve partner's SCRIPTS_DIR before SCP pull.

fallback.php page: added controls card (PARTNERSHIP_ENABLED, FALLBACK_ENABLED,
FALLBACK_RSYNC_ENABLED toggles), status grid, and settings card.

README and Manual updated for System_Essentials, Watchdogs, Fallback, Rsync,
Media, Monitors, Orchestrators, Partnership: added new scripts (conf_sync,
conf_cache_save/restore, conf_cache_watchdog, play_state_sync, start_webhook_listener,
upgrade_webhook_handler), corrected all stale /boot/config/ state file paths to
$STATE_DIR/$DATA_DIR, noted webgui/php_fpm/mover/user_scripts scripts moved to
Plugin/unraid/System_Essentials, fixed start_webhook_listener.sh header (Node.js,
not PHP -S).

Fallback/Manual-Fallback.md

@@ -37,11 +37,11 @@ up required before handback sequence starts. **(default: 3)**
 ---
 
 ```
-FALLBACK_STATE_FILE=/boot/config/fallback_state.db
+FALLBACK_STATE_FILE="$STATE_DIR/fallback_state.db"
 ```
-Path to the persistent state file. Lives on `/boot/` intentionally — survives reboots.
-If the server was in FALLBACK state when it rebooted, it resumes FALLBACK on restart
-rather than assuming everything is normal.
+Path to the persistent state file. In `$STATE_DIR` — survives reboots whether storage
+mode is internal (boot device) or appdata (array). If the server was in FALLBACK state
+when it rebooted, it resumes FALLBACK on restart rather than assuming everything is normal.
 
 ---
 
@@ -172,7 +172,7 @@ daily_sync_maintenance.sh uses, in the opposite direction. No separate TIER4 lis
 FALLBACK_ENABLED=true
 FALLBACK_CHECK_INTERVAL=30
 FALLBACK_HANDBACK_STRIKES=3
-FALLBACK_STATE_FILE=/boot/config/fallback_state.db
+FALLBACK_STATE_FILE="$STATE_DIR/fallback_state.db"
 FALLBACK_RSYNC_ENABLED=true
 EXTERNAL_IP=8.8.8.8
 FALLBACK_TEST_BLOCK_WAIT=60
@@ -293,7 +293,10 @@ FALLBACK_HOST2_WRITEBACK_TIER1=(
 
 ## ━━━ STATE FILE REFERENCE ━━━
 
-Location: `/boot/config/fallback_state.db` (survives reboots)
+Location: `$STATE_DIR/fallback_state.db` (survives reboots — boot device or appdata)
+
+> In a shell where load_config.sh is not sourced, use the full path:
+> `/boot/config/plugins/varaverk/State_Files/fallback_state.db` (internal storage mode)
 
 ```
 state=NORMAL            # NORMAL | FALLBACK | NO_INTERNET | DARK
@@ -304,8 +307,8 @@ tier3_started=false     # whether Tier 3 containers started
 tier4_started=false     # whether Tier 4 containers started
 ```
 
-View state: `cat /boot/config/fallback_state.db`  
-Check state: `fallback.sh --status`
+View state: `fallback.sh --status` (preferred — parsed output)  
+Raw file: `cat "$STATE_DIR/fallback_state.db"` (requires STATE_DIR set, or use full path)
 
 The file is managed exclusively by fallback.sh. Do not edit it while fallback.sh is
 running — the next cycle will overwrite your changes. Use the Manual State Reset
@@ -384,7 +387,7 @@ servers must be running it continuously for mutual coverage.
 pgrep -f "fallback.sh"
 
 # Check the state file
-cat /boot/config/fallback_state.db
+cat "$STATE_DIR/fallback_state.db"
 ```
 
 Start via User Scripts plugin on both servers.
@@ -405,7 +408,7 @@ in smart mode — a non-NORMAL state at digest time needs attention.
 
 ```bash
 fallback.sh --status          # full state snapshot
-cat /boot/config/fallback_state.db    # raw state file
+cat "$STATE_DIR/fallback_state.db"    # raw state file
 ```
 
 ---
@@ -426,7 +429,7 @@ fallback_test.sh
 
 # Step 3 — check state after test completes
 fallback.sh --status
-cat /boot/config/fallback_state.db
+cat "$STATE_DIR/fallback_state.db"
 ```
 
 If the test doesn't complete cleanly, the state file may be left in FALLBACK. The
@@ -459,11 +462,14 @@ ping -c 5 [remote-tailscale-ip]
 **Stop fallback.sh first (via User Scripts Abort), then reset:**
 
 ```bash
+# Set STATE_DIR (or source load_config.sh to get it from the environment)
+source /boot/config/plugins/varaverk/load_config.sh
+
 # View current state
-cat /boot/config/fallback_state.db
+cat "$STATE_DIR/fallback_state.db"
 
 # Write a clean NORMAL state
-cat > /boot/config/fallback_state.db << 'EOF'
+cat > "$STATE_DIR/fallback_state.db" << 'EOF'
 state=NORMAL
 fallback_start=0
 handback_strikes=0
@@ -473,7 +479,7 @@ tier4_started=false
 EOF
 
 # Verify the write
-cat /boot/config/fallback_state.db
+cat "$STATE_DIR/fallback_state.db"
 ```
 
 Restart fallback.sh via User Scripts plugin. It will resume from NORMAL on its next cycle.
@@ -510,7 +516,7 @@ Can this server reach the remote Tailscale IP?
 
 What does fallback.sh report?
   → fallback.sh --status
-  → cat /boot/config/fallback_state.db
+  → cat "$STATE_DIR/fallback_state.db"
 ```
 
 ### Handback Not Completing
@@ -559,7 +565,7 @@ If it has happened:
 
 3. Understand the state before resetting
    fallback.sh --status
-   cat /boot/config/fallback_state.db
+   cat "$STATE_DIR/fallback_state.db"
 
 4. Perform Manual State Reset above on the server in a bad state