feat(event-module): implement Event_Module::boot()

[MathieuLamiot]

Description

Moves event tracking initialisation, the public extensibility API call, and the `sybgo/track-events` Ability registration out of `Sybgo::init_event_tracking()` and `init_abilities()` into `Event_Module::boot()`, making the event-domain wiring independently testable as a named method.

Closes #95

Type of change

• Sub-task of Introduce Feature Modules to own WP integration by domain #93
• Enhancement (non-breaking change which improves an existing functionality).

Detailed scenario

What was tested

Behaviour is identical to develop — the same hooks, API, and ability are registered; only the location of that wiring changed. Manual verification on a local wp-env install:

1. Activated the plugin — no fatal errors, all admin pages loaded normally.
2. Ran wp cron event list | grep sybgo — all four cron events present and scheduled as before.
3. Ran wp cron event run sybgo_freeze_weekly_report — weekly report frozen successfully; event tracking continued writing rows to wp_sybgo_events before and after the freeze.
4. Navigated to WP Admin → Dashboard — widget showed current-week event counts, confirming Event_Tracker is still active.

How to test

1. Check out feat/event-module-95 and run composer dump-autoload inside wp-plugin/.
2. Boot wp-env: cd tests/e2e && npx wp-env start.
3. Run unit tests: cd wp-plugin && vendor/bin/phpunit --testsuite=Unit — 4 new EventModuleTest tests pass; 5 pre-existing DashboardWidgetTest errors (unrelated, present on develop too).
4. Publish a post via WP Admin or wp post create --post_title="Test" --post_status=publish.
5. Verify the event was tracked: wp db query "SELECT event_type FROM wp_sybgo_events ORDER BY id DESC LIMIT 1" — should show post_published.
6. Run wp cron event run sybgo_freeze_weekly_report and confirm the report freezes without PHP errors in the debug log.

Affected Features & Quality Assurance Scope

Event tracking, the public extensibility API (sybgo_init_api), and the sybgo/track-events Ability are affected — behaviour unchanged but wired from a new location. All other plugin features are untouched.

Technical description

Event_Module::boot() now:

1. Calls Factory::create_event_repository() and create_aggregated_event_repository(), constructs Event_Tracker, calls init() on it, and stores it via Factory::set_event_tracker().
2. Calls sybgo_init_api($event_repo) to expose the public extension API.
3. Schedules a closure on add_action('init', …, 5) that calls Ability_Manager::register('sybgo/track-events', …) with the translated label and description. Priority 5 ensures registration runs before Ability_Manager::init(), which is now deferred to add_action('init', …, 20) inside Sybgo::init().

The init action deferral preserves the fix for the WP 6.7+ textdomain early-loading bug: calling __() during plugins_loaded before the text domain is loaded triggers _doing_it_wrong() → trigger_error() → captured by Error_Tracker, polluting aggregated event counts.

Sybgo::init_event_tracking() is deleted (dead code after extraction). init_abilities() now only handles sybgo/generate-summary, which will move to AI_Module in #98.

See wp-plugin/docs/development.md — Feature Module Architecture section.

New dependencies

None.

Risks

None identified. The ability registration timing (priority 5 → priority 20 on init) is the only subtle change; it preserves the existing WP7 deferral fix and is covered by EventModuleTest::test_boot_registers_track_events_on_init_hook_priority_5.

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

None.

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.)