Give the AI subsystem one profile table and one collection, read everywhere

Plugin/unraid/Tools/ai_chat_worker.php

@@ -404,6 +404,11 @@ if ($can('conf_lookup')) {
 // Varaverk question as chat produces a confident invention about the user's system, which is
 // precisely what retrieval exists to prevent. The user always knows which contract is in force,
 // and the strict profile is the default.
+//
+// These stay here rather than in include/ai_profiles.php with the rest of what a profile is.
+// That file exists to kill duplication, and these prompts have exactly one reader — moving them
+// would relocate the most delicate text in the subsystem without removing a single copy of
+// anything. The registry owns the ids; the ids branch here. The trailing else is varaverk.
 if ($profile === 'chat') {
     // A polite instruction is not a guard. Asked "what does mover_stop.sh do in my setup", the
     // model invented an answer and dressed it in real memory facts so it read as authoritative.
@@ -652,7 +657,7 @@ $messages[] = ['role' => 'user', 'content' => $question];
 // them, which is why the report prints here: it describes the request that is about to be made,
 // not a reconstruction of one.
 if ($explain) {
-    $caps = array_keys(array_filter(VV_AI_CAPS, fn($ps) => in_array($profile, $ps, true)));
+    $caps = vv_ai_profile_caps($profile);
     $sysChars = strlen($system);
 
     echo "QUESTION   ", $question, "\n";

Plugin/unraid/Tools/api_cache_writer.php

@@ -91,19 +91,23 @@ $t = microtime(true);
 // Call vv_api_data() once — result is static-cached for the rest of this process.
 vv_api_data();
 
-// Must stay in step with api/monitor.php's own block. This file is what the Monitor tab
-// normally reads — the endpoint only assembles a payload on a cache miss — so a key added there
-// and not here leaves the card that consumes it loading forever on every ordinary page load,
-// and working on the one request that happens to miss the cache.
+// ── AI ────────────────────────────────────────────────────────────────────────
+// One collection, two consumers. vv_ai_stats() is the expensive part of the AI subsystem —
+// roughly a second, most of it waiting on Ollama and nvidia-smi — and it is written to its own
+// cache here so the AI tab's banner, the Scheduler dock and the Monitor row all read the same
+// numbers from the same moment instead of each paying for their own.
+//
+// The monitor block is derived from that same array rather than collected again. Must stay in
+// step with api/monitor.php's own block: this file is what the Monitor tab normally reads, since
+// the endpoint only assembles a payload on a cache miss, so a key added there and not here
+// leaves the card that consumes it loading forever on every ordinary page load and working only
+// on the one request that happens to miss.
 $_vv_ai = null;
 if (vv_ai_ui_on()) {
     require_once $_base . '/include/ai.php';
-    $_vv_ai = [
-        'model'   => vv_ai_config()['model'],
-        'runtime' => vv_ai_runtime_stats(),
-        'index'   => vv_ai_index_stats(),
-        'tokens'  => vv_ai_token_stats()['today'] ?? null,
-    ];
+    $_vv_ai_stats = vv_ai_stats();
+    vv_cache_write('ai', $_vv_ai_stats);
+    $_vv_ai = vv_ai_monitor_block($_vv_ai_stats);
 }
 
 $monitor = [