Survive a stale platform-tools instead of 500ing the whole site

Deploying the local-SMTP commit took fitme3070.pt down:

    PHP Warning: require_once(.../shared/platform-tools/compat_secrets.php):
    Failed to open stream: No such file or directory
    in .../config/functions_secrets.php on line 20

config/functions_secrets.php is loaded on every request, so a hard require_once
on a submodule file is a site-wide fatal — public pages included — whenever
shared/platform-tools lags the code that needs it. It lagged: the server is
still on 603ff84, which predates compat_secrets.php, because "Atualizar
submódulo" was itself broken (fixed in 3626080, which the site had to be up to
deploy). A missing file should not be able to close that loop.

Three requires hardened, each to the failure the caller can actually report:

  - config/functions_secrets.php: falls back to plaintext passthrough helpers
    and logs loudly. secrets_available() then returns false, which is exactly
    what the Comunicações page already renders a warning banner for — so
    nothing silently pretends to be encrypted while the site keeps serving.

  - config/functions_queue.php (_flush_email): throws instead of fataling. A
    fatal killed the request outright, so flush_message()'s catch never ran and
    the row sat in 'sending' forever with no explanation. It now lands in
    last_error where the Monitor page shows it.

  - views/sysadmin/comms.php: renders "Submódulo desactualizado" naming the
    missing files, rather than a blank 500 on the page you would open to
    diagnose mail in the first place.

Verified by loading config/functions_secrets.php with no shared/ directory
present: the bootstrap completes, the warning is logged once, secrets_available()
is false, and setting_secret()/setting_or_env() still return usable values.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

views/sysadmin/comms.php

@@ -12,8 +12,27 @@ require __DIR__ . '/../../config/db.php';
 require __DIR__ . '/../../config/functions.php';
 $user = require_sysadmin();
 
-require_once __DIR__ . '/../../shared/platform-tools/functions_mail.php';
-require_once __DIR__ . '/../../shared/platform-tools/functions_settings.php';
+// Same reasoning as config/functions_queue.php: a stale submodule should show
+// an explanation, not a blank 500 on the page you would go to in order to
+// diagnose mail.
+$_ptRoot  = __DIR__ . '/../../shared/platform-tools/';
+$_ptMissing = [];
+foreach (['functions_mail.php', 'functions_settings.php'] as $_ptFile) {
+    is_file($_ptRoot . $_ptFile) ? require_once $_ptRoot . $_ptFile : $_ptMissing[] = $_ptFile;
+}
+if ($_ptMissing) {
+    $page_title = 'Comunicações';
+    include __DIR__ . '/../../includes/header.php';
+    echo '<div class="container" style="max-width:720px;"><div class="alert alert-danger">'
+       . '<h1 class="h5">Submódulo desactualizado</h1>'
+       . '<p class="mb-1">Faltam em <code>shared/platform-tools/</code>: <code>'
+       . htmlspecialchars(implode('</code>, <code>', $_ptMissing)) . '</code>.</p>'
+       . '<p class="mb-0">Actualize o submódulo em <a href="' . htmlspecialchars(base_url('views/sysadmin/platform_update.php'))
+       . '">Sistema → Actualizações</a> (ou envie a pasta por FTP) e volte a esta página.</p>'
+       . '</div></div>';
+    include __DIR__ . '/../../includes/footer.php';
+    exit;
+}
 
 $repo_root = dirname(__DIR__, 2);
 $saved     = false;