feat(ai-module): implement AI_Module — register generate-summary ability (#98)

[MathieuLamiot]

Description

AI_Module::boot() now owns the sybgo/generate-summary WordPress 7 Ability registration, removing the last domain-specific responsibility from Sybgo::init_abilities() — which is now deleted. All five feature modules are functionally wired for their ability registrations.

Closes #98

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• Sub-task of Introduce Feature Modules to own WP integration by domain #93
• Chore
• Release

Detailed scenario

What was tested

No manual testing performed for this sub-task. The change is a pure internal code reorganization: the sybgo/generate-summary ability was previously registered inside Sybgo::init_abilities() via an anonymous closure and is now registered inside AI_Module::boot() via a public named class. The external behaviour (which WP7 ability is registered, its label, permission, and execute callback logic) is identical.

Automated coverage: 4 new unit tests in AIModuleTest verify the deferred registration pattern, that the ability name and args are correct, and that the execute callback returns null when the AI summariser is unavailable or no frozen report exists.

How to test

1. Check out this branch and activate the plugin on a WordPress 7+ install.
2. Verify no PHP errors or warnings appear in the debug log on plugin activation.
3. Confirm the sybgo/generate-summary ability is registered:

   wp ability list --fields=name,label | grep sybgo

   Expected: sybgo/generate-summary with label "Generate Weekly Summary" is present.
4. On a WordPress < 7 install, repeat step 3 — the ability should not appear (guarded by Ability_Manager).
5. Run the unit tests: cd wp-plugin && vendor/bin/phpunit --testsuite Unit --filter AIModuleTest
   Expected: 4 tests, all green.

Affected Features & Quality Assurance Scope

• WP7 Ability API: sybgo/generate-summary registration timing and registration path
• Sybgo::init() orchestration (removal of init_abilities() call and method)
• No user-visible UI change; no admin pages, cron events, or AJAX actions changed

Technical description

Documentation

AI_Module::boot() wraps the ability registration in add_action('init', ..., 5) so that __() evaluates after the sybgo text domain loads (calling __() during plugins_loaded on WP 6.7+ triggers _doing_it_wrong() → trigger_error(), which would be captured by Error_Tracker and pollute event counts).

Ability_Manager::init() is deferred to init at priority 20 from Sybgo::init(), guaranteeing that all modules' register() calls at priority 5 complete before the manager wires abilities into WP.

With this PR, Sybgo::init_abilities() is fully empty and has been removed along with its call in init().

See wp-plugin/docs/development.md — new "WP7 Ability API Registrations" section documents both registered abilities and the priority ordering rationale.

New dependencies

None.

Risks

None identified. The ability registration logic and execute callback are byte-for-byte identical to the removed init_abilities() closure — only the ownership and testability change.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria.
• 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

Manual validation in "What was tested" is not applicable: this is a pure internal reorganisation with no UI change. The existing E2E test suite covers the AI summary button end-to-end; the unit tests cover the registration path directly.

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