Put everything Varaverk persists under one root, state included

Plugin/unraid/include/config.php

@@ -103,8 +103,20 @@ $_vv_cfg = @parse_ini_file(PLUGIN_CFG) ?: [];
 define('SCRIPTS_DIR', $_vv_cfg['SCRIPTS_DIR'] ?? '/boot/config/plugins/varaverk');
 define('CONF_DIR',    SCRIPTS_DIR . '/Configurations');
 define('DEPLOY_DIR',  SCRIPTS_DIR . '/Deployment');
-define('DATA_DIR',    SCRIPTS_DIR . '/data');
-define('STATE_DIR',   SCRIPTS_DIR . '/State_Files');
+// DATA_DIR is the one on-disk root; everything Varaverk persists lives under it in a
+// subdirectory named for what the files are. Mirrors the same block in master.conf, which is
+// where the shell layer reads them from — these are derived from SCRIPTS_DIR rather than parsed
+// so that a conf that has not upgraded yet still resolves, and so this file keeps working when
+// master.conf is missing entirely (setup, first boot, a botched pull).
+//
+// STATE_DIR moved from SCRIPTS_DIR/State_Files to DATA_DIR/state and kept its name, which is why
+// the 23 call sites in this layer that build on it needed no edits at all.
+define('DATA_DIR',         SCRIPTS_DIR . '/data');
+define('DB_DIR',           DATA_DIR . '/db');
+define('STATE_DIR',        DATA_DIR . '/state');
+define('AI_DATA_DIR',      DATA_DIR . '/ai');
+define('CACHE_BACKUP_DIR', DATA_DIR . '/cache');
+define('LOG_ARCHIVE_DIR',  DATA_DIR . '/logs');
 define('LOG_DIR',     '/var/log/varaverk');
 // User-authored custom scripts (scheduler page "+ Create Script") — kept outside the git
 // repo entirely, alongside the User Scripts plugin's own storage. Any *.sh file placed
@@ -204,12 +216,21 @@ function vv_push_setup_state(): void {
                 break;
             }
         }
-        $remoteStatePath = $remoteSD . '/State_Files/varaverk_setup.db';
-        shell_exec($sshBase . ' "mkdir -p ' . escapeshellarg(dirname($remoteStatePath)) . '" 2>/dev/null');
-        $dest = escapeshellarg('root@' . $ip . ':' . $remoteStatePath);
-        exec('scp -i ' . escapeshellarg($sshKey)
-            . ' -o ConnectTimeout=10 -o StrictHostKeyChecking=no'
-            . ' ' . escapeshellarg(VV_SETUP_STATE_FILE) . ' ' . $dest . ' 2>&1');
+        // Which layout the partner uses is decided ON the partner, not assumed here. State moved
+        // from SCRIPTS_DIR/State_Files to DATA_DIR/state, and this file is written to whichever
+        // one that host will actually read — a setup state pushed to the directory the partner
+        // does not read is worse than not pushing it, because the push reports success.
+        //
+        // The order matters: prefer the new path, fall back to the old ONLY if it already exists.
+        // A partner that has neither is a fresh install on current code, which reads the new one.
+        // Piped over ssh rather than scp'd so the resolution and the write are the same call —
+        // scp needs the path decided here, which is the thing that cannot be known here.
+        $remoteResolve = 'sf="' . $remoteSD . '/data/state"; '
+                       . '[ -d "$sf" ] || { [ -d "' . $remoteSD . '/State_Files" ] '
+                       . '&& sf="' . $remoteSD . '/State_Files"; }; '
+                       . 'mkdir -p "$sf" && cat > "$sf/varaverk_setup.db"';
+        exec('cat ' . escapeshellarg(VV_SETUP_STATE_FILE) . ' | '
+            . $sshBase . ' ' . escapeshellarg($remoteResolve) . ' 2>&1');
     }
 }
 
@@ -612,13 +633,22 @@ function vv_auto_create_api_key(string $hostId, string $confFile): array {
     return ['ok' => true, 'key_preview' => $key ? substr($key, 0, 8) . '...' . substr($key, -4) : 'registered'];
 }
 
-// Build a bash command that reads a state file from the REMOTE host's State_Files/.
+// Build a bash command that reads a state file from the REMOTE host's state directory.
 // Reads the remote's varaverk.cfg to resolve their SCRIPTS_DIR (may differ from ours
 // when the remote is in appdata mode). Falls back to the internal plugin path.
+//
+// The state directory is probed on the far side rather than assumed, because it moved:
+// SCRIPTS_DIR/State_Files became DATA_DIR/state, and a partner may not have pulled that yet.
+// This is the call that reads the partner's fallback_state.db, and a miss returns an empty
+// string — which the callers cannot distinguish from "partner is in NORMAL state". Reading the
+// wrong directory would therefore not look like an error, it would look like an answer. Probing
+// also means the two hosts can be upgraded in either order.
 function vv_remote_state_cmd(string $filename): string {
     $fn = basename($filename);
     return 'sd=$(grep -m1 SCRIPTS_DIR= /boot/config/plugins/varaverk/varaverk.cfg 2>/dev/null'
-         . ' | cut -d\'"\' -f2); cat "${sd:-/boot/config/plugins/varaverk}/State_Files/' . $fn . '" 2>/dev/null';
+         . ' | cut -d\'"\' -f2); sd="${sd:-/boot/config/plugins/varaverk}"; '
+         . 'sf="$sd/data/state"; [ -d "$sf" ] || sf="$sd/State_Files"; '
+         . 'cat "$sf/' . $fn . '" 2>/dev/null';
 }
 
 // Local LAN IP via routing table — static-cached per request.