Watch the auth stack on a schedule, so nobody has to open the tab

Both checks already answered their question on demand and both needed
somebody to press a button on the right row. One host here has returned
nothing but 5xx for months.

Filed as findings, which is the existing answer to a condition that
persists while nobody is looking. Grouped by cause rather than by
hostname: a default policy of bypass produced twenty-two findings that
were one sentence repeated, and they have one fix between them.

Plugin/unraid/include/ai_repair.php

@@ -92,6 +92,13 @@ const VV_AI_FINDING_KINDS = [
     'container_fault' => 'a container is logging a fault about its own environment',
     'media_misfiled'  => 'a series is shelved somewhere its own metadata does not support',
     'watchdog_strike' => 'a watchdog has counted something far enough to be worth a record',
+    // The auth stack's two. Neither is a conf problem — one is a service behind a proxy host that
+    // has stopped answering, the other is a hostname put behind Authelia that Authelia then lets
+    // everyone past. They are recorded here rather than only drawn on the Auth tab because both
+    // are conditions that persist for weeks without anyone opening that tab: one host on this
+    // installation has served nothing but 5xx for months.
+    'proxy_down'      => 'a proxy host has been failing long enough that it is not a blip',
+    'access_open'     => 'a hostname behind an auth_request block is not actually protected by any rule',
 ];
 
 // Which kinds are a statement about Varaverk's configuration, and which are a statement about
@@ -205,6 +212,13 @@ function vv_ai_finding_severity(array $f): string {
         'missing_value'  => 'error',   // configured to use something that was never supplied
         'unreachable'    => 'warn',    // may be transient; the strike system is what escalates it
         'unknown_target' => 'warn',
+        // A hostname deliberately put behind authentication that authenticates nobody is the one
+        // finding here that is worse the longer it goes unnoticed, and it is never transient —
+        // it is a state of the configuration, not a passing failure.
+        'access_open'    => 'error',
+        // The sweep only files this after the outage has already outlasted a restart, so it is
+        // past the point where the strike system would still be deciding.
+        'proxy_down'     => 'error',
         default          => 'warn',
     };
 }