feat(modules): scaffold Module_Interface and five feature module stubs

[MathieuLamiot]

Description

Introduces the wp-plugin/modules/ directory with a Module_Interface contract and five empty feature module stubs (Event, Report, Email, AI, Settings). Sybgo::init() now creates the three managers and boots all modules via build_modules(), establishing the architecture that sub-issues #95–#99 will fill in.

Closes #94

Type of change

• Sub-task of Introduce Feature Modules to own WP integration by domain #93
• New feature (non-breaking change which adds functionality).

Detailed scenario

What was tested

All five module boot() methods are no-ops at this stage, so the plugin's runtime behaviour is identical to the develop baseline. Manual verification:

1. Activated the plugin on a local wp-env install — no fatal errors, admin pages loaded correctly.
2. Ran wp cron event list — all four sybgo cron events still scheduled (freeze, send, cleanup, retry).
3. Navigated to WP Admin → Settings → Sybgo and WP Admin → Reports — both pages rendered without errors.
4. Ran wp cron event run sybgo_freeze_weekly_report — report frozen as expected; legacy callbacks still wired via init_cron_schedules().

How to test

1. Check out the branch and run composer dump-autoload in wp-plugin/.
2. Boot a wp-env: cd tests/e2e && npx wp-env start.
3. Confirm the plugin activates without PHP errors: wp --path=... eval 'echo "ok";'.
4. Run unit tests: cd wp-plugin && vendor/bin/phpunit --testsuite=Unit — expect 49 passing, 5 pre-existing errors unrelated to this PR (Error_Tracker::get_effective_daily_cap stub missing in develop).
5. Verify all four cron events still appear: wp cron event list | grep sybgo.
6. Visit WP Admin → Reports and WP Admin → Settings → Sybgo — both pages should load normally.

Affected Features & Quality Assurance Scope

The existing admin UI, cron callbacks, abilities, and event tracking are entirely unchanged at runtime — all legacy init_*() sub-methods remain active and the new modules' boot() methods are no-ops. Risk surface is limited to the autoloader picking up the new modules/ classmap entry.

Technical description

Documentation

Sybgo::init() now instantiates Cron_Manager, Admin_Manager, and Ability_Manager, calls boot() on each module returned by build_modules(), then delegates to the legacy init_*() methods (which stay intact until #95–#99 each fill a module). This dual-path lets the refactor proceed incrementally with a passing test suite at every step.

Each module class in wp-plugin/modules/ receives only the subset of managers it will eventually need (see the plan), making future constructor dependencies explicit before any logic is added. @phpstan-ignore property.onlyWritten annotations suppress PHPStan warnings on properties that are intentionally stored but not yet read in the stub boot().

See wp-plugin/docs/development.md for the updated project structure and a new "Feature Module Architecture" section explaining the pattern and where new domain wiring belongs.

New dependencies

None.

Risks

None identified. All boot() methods are no-ops; existing behaviour is 100% preserved by the legacy init_*() paths.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionable.

Unticked items justification

Tests: The module stubs have no logic to unit-test beyond "the class loads and boot() returns void". Test coverage for each module's actual behaviour is scoped to sub-issues #95–#99.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.)
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)