Add structured headers to the PHP pages layer

Documents each tab's purpose, what it renders, and which endpoints it polls.
Pages that start with markup get the header in a <?php ?> block so it never
reaches the browser.

Also corrects the layer diagram in README-unraid.md: eight of eleven pages hold
no PHP logic and poll api/ for everything — only auth, monitor and scheduler
require an include/ file directly.

Plugin/unraid/pages/settings.php

@@ -1,4 +1,33 @@
 <?php
+// ═══════════════════════════════════════════════════════════════════════════════════════════════
+// PURPOSE
+//   Settings tab. Varaverk's own configuration — storage mode, global toggles, and the conf
+//   fields that are not specific to any one subsystem.
+//
+// DESIGN PRINCIPLES
+//   Edits go through the same conf machinery the scheduler page uses (include/confform.php),
+//   so a value changed here is written exactly the way a value changed anywhere else is —
+//   surgically, preserving comments and ordering.
+//
+//   Storage mode is presented as a migration, not a setting. Changing it moves the whole
+//   installation and regenerates the cron, which is why it routes through api/storage.php
+//   rather than a plain conf write.
+//
+// OPERATIONAL SAFEGUARDS
+//   The storage-mode change is confirmed before it runs. It is the most destructive operation
+//   reachable from the UI — rsync --delete, rm -rf, and a rewrite of every derived path.
+//
+//   Conf writes are surgical. A settings page that regenerated master.conf would destroy the
+//   comment blocks that document every threshold in it.
+//
+//   Values are escaped on render and on write-back.
+//
+// RENDERS
+//   Storage mode selector, global toggles, general conf fields
+//
+// DEPENDS ON
+//   api/confform.php  conf read/write   → include/confform.php
+//   api/storage.php   storage-mode migration
 $_myHost  = vv_detect_host();
 $_vars    = vv_conf_vars();
 $_myId    = strtoupper($_myHost);