Extract Admin_Manager as a pure admin registration utility

[MathieuLamiot]

Description

Closes #89

Part of EPIC #86 — refactor class-sybgo.php into focused OOP classes. Extracts all WordPress admin bootstrapping into a new Admin_Manager class following the "registration utility" pattern established in the EPIC.

Type of change

• Enhancement (non-breaking change which improves an existing functionality).
• Sub-task of EPIC: Refactor class-sybgo into focused OOP classes #86

Detailed scenario

What was tested

• Verified all 45 unit tests pass (cd wp-plugin && vendor/bin/phpunit --testsuite Unit)
• Verified PHPCS reports no issues (cd wp-plugin && composer phpcs)
• Verified PHPStan reports no issues (cd wp-plugin && vendor/bin/phpstan analyse --memory-limit=1G)
• Confirmed Admin_Manager::init() is the sole entry point for admin bootstrapping — no admin logic remains in class-sybgo.php

How to test

1. Clone the repo and check out feat/admin-manager-89
2. cd wp-plugin && composer install
3. Activate the plugin on a local WordPress install
4. Navigate to WP Admin > Dashboard — verify the Sybgo dashboard widget renders
5. Navigate to WP Admin > Settings > Sybgo — verify the settings page renders, configure recipients and save
6. Click "Run Cleanup" on the settings page — verify it processes and redirects back with a count
7. Navigate to WP Admin > Sybgo > Reports — verify the reports page renders
8. Confirm admin CSS/JS load only on plugin pages (dashboard, settings, reports), not on other admin pages

Affected Features & Quality Assurance Scope

• WordPress admin: Dashboard widget, Settings page, Reports page
• Admin asset enqueue (CSS/JS)
• Manual cleanup form handler

Technical description

Documentation

Admin_Manager (wp-plugin/admin/class-admin-manager.php) is a pure registration utility following the same pattern as Cron_Manager and Ability_Manager:

• register_page(object $page) — accumulates admin page instances
• register_cleanup_handler(callable $handler) — stores the cleanup form callback
• register_asset_enqueuer(callable $enqueuer) — stores the asset enqueue callback
• init() — calls init() on each page and wires the registered callbacks to WP actions

All wiring logic (which pages to instantiate, what the cleanup handler does, which hooks to enqueue on) lives in Sybgo::init_admin() as closures. Admin_Manager has no knowledge of Factory, Dashboard_Widget, or any concrete page class.

class-sybgo.php now delegates all admin bootstrapping to init_admin(), which creates the manager, registers everything, and calls init().

See wp-plugin/docs/development.md for updated constructor dependencies and project structure.

New dependencies

None.

Risks

None identified. Pure extraction — no logic change. All closures were previously inline in class-sybgo.php; they now live in Sybgo::init_admin().

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