feat: run pending schema migrations from the admin UI

[anonymoususer72041]

Summary

Adds a dedicated maintenance page (?m=install&a=maint) reachable through the existing "Maintenance Required" notice, so a logged-in site administrator can bring an already-installed database up to the current schema without leaving the application for the Installation Wizard.

• modules/install/CATSUI.php now handles a=maint: gates on a logged-in SA session, no-ops when no migrations are pending, and renders the new Maintenance.tpl.
• modules/install/Maintenance.tpl provides a standalone progress page (CSRF token, lib.js, install.js, install.css) with a Start button and progress bar.
• modules/install/ajax/maint.php gains an installed-system auth path: when INSTALL_BLOCK exists it requires a logged-in SA session and a valid CSRF token; the fresh-installer path is unchanged.
• js/install.js adds a maintenanceOnly flag so the chunked Installpage_maint loop redirects to index.php on completion and surfaces an error block instead of continuing into installer-only steps (a=reindexResumes, etc.).
• lib/ModuleUtility.php calls SchemaMigrationStatus::clearCache() after each applied install migration and after the NULL-snapshot finalization, so the pending-migration gate re-evaluates on the next request.
• index.php excludes ?m=install&a=maint from the pending-migration page gate; modules/login/PendingMigrations.tpl now links to that page instead of installwizard.php.

Motivation

Since #803, OpenCATS blocks all logged-in, non-public requests while install schema migrations are pending and points admins at the Installation Wizard. For an existing installation that only needs a schema upgrade, the wizard is heavier than necessary: it re-enters the full installer flow (questions, demo data, reindex) and forces the admin out of the application UI. This PR gives admins a focused, in-app path that runs the same chunked migration runner and returns them to the application once the database is current.

[RussH]

My review shows that this duplicates some of the existing AJAX bootstrap and security handling. Could you make one small change before we merge?

In modules/install/ajax/maint.php, the config, session and CSRF setup is being handled again locally:

include_once('./config.php');
include_once(LEGACY_ROOT . '/constants.php');
include_once(LEGACY_ROOT . '/lib/DatabaseConnection.php');
include_once(LEGACY_ROOT . '/lib/Session.php');

@session_name(CATS_SESSION_NAME);
@session_start();

The request already comes through the existing ajax.php dispatcher via AJAX_callCATSFunction(), which loads the required dependencies, starts the session and validates the CSRF token. We also now have the shared ajax/bootstrap.php, which is used by other direct AJAX endpoints.

Could we remove the duplicated bootstrap, session and CSRF handling here, and leave this endpoint responsible only for its maintenance-specific checks, particularly confirming that the user is logged in and has SA access?

That should keep the security behaviour in one place and follow the existing OpenCATS AJAX pattern.

Once this is done, good to merge!