Refactor module lifecycle and split high-complexity modules

Problem

The module loader is serviceable for 1.6.0, but the module lifecycle is under-specified for future growth. Modules currently choose between extending AbstractModule and implementing ModuleInterface directly. That creates inconsistent settings access, inconsistent dependency checks, and uneven testability.

The largest example is src/Modules/Cache/PageCache.php, which currently owns request eligibility, output buffering, cache file I/O, stats, preload queue handling, sitemap discovery, CDN purge, async regeneration, and admin observability. The class works, but the blast radius is too large for ongoing feature work.

Why this is not a 1.6.0 blocker

Changing module boundaries is higher risk than the release needs. It touches cache behavior, settings reads, hooks, and public runtime behavior. For 1.6.0 we should only ship targeted compatibility-safe fixes.

Proposed direction

Introduce a clearer module contract without changing public option keys or existing hook behavior:

• Keep Registry as the central source of module classes.
• Add explicit module metadata or descriptors for module id, setting keys, dependencies, and runtime surface.
• Standardize settings injection so direct ModuleInterface modules do not need to repeatedly read options.
• Add dependency checks for optional integrations before hooks are registered.
• Split Page Cache into focused services such as cache eligibility, cache storage, preloader, invalidator, remote purge, and observability admin UI.
• Add loader-level unit tests for missing classes, invalid classes, disabled modules, optional dependencies, and idempotency expectations.

Acceptance criteria

• No public option/meta keys are renamed or migrated unnecessarily.
• Existing filters/actions continue to fire with the same behavior unless explicitly documented.
• Heavy modules are split behind private/internal services with focused tests.
• Optional integrations can declare dependencies and fail closed when unavailable.
• Module loader behavior is covered by unit tests.
• Release ZIP contents remain production-only.

Validation

• composer test
• composer phpstan
• PHPCS on changed PHP files
• Plugin activation smoke test
• Frontend smoke test with at least Page Cache, Menu Cache, Assets Manager, and WooCommerce-related settings toggled where dependencies exist

Start by reading Registry, AbstractModule, ModuleInterface, and src/Modules/Cache/PageCache.php to map the current lifecycle and responsibilities. Review the proposed loader-level unit-test cases and validation commands before defining boundaries. Done means preserving public option keys and hook behavior, splitting heavy modules behind focused services, covering loader behavior, and passing the listed validation checks.