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.