Include PHP error aggregated events in AI summary prompt

[MathieuLamiot]

Description

Closes #59

PHP errors tracked by Error_Tracker were never visible to the AI summarizer — the prompt only included singular events. This change feeds aggregated PHP error rows into the prompt so AI-generated summaries can mention notable errors (type, count, frequency) alongside regular site activity.

Type of change

• Enhancement (non-breaking change which improves an existing functionality).

Detailed scenario

What was tested

Scenario 1 — Active report with PHP errors (dashboard widget)

1. Seeded wp_sybgo_aggregated_events with two php_error rows (report_id = 0): one warning (5 occurrences) and one fatal_error (1 occurrence).
2. Opened WP Admin → Dashboard widget → clicked "Get AI Summary".
3. Temporarily added Logger::debug($prompt) and confirmed the prompt contained a "## PHP Errors" section listing both signatures with correct level, message snippet, and occurrence counts.
4. Removed the debug line and confirmed the generated summary referenced the errors naturally.

Scenario 2 — Frozen report with PHP errors (reports page)

1. Ran a freeze with PHP error rows assigned to the resulting report_id.
2. Opened the frozen report detail page → clicked "Generate AI Summary".
3. Confirmed the prompt included the PHP Errors section using the frozen report_id.

Scenario 3 — No PHP errors (backward compatibility)

1. Ensured wp_sybgo_aggregated_events had no php_error rows for the current period.
2. Generated an AI summary — confirmed the "## PHP Errors" section was absent and the rest of the summary was identical to pre-change output.

How to test

1. Activate the sybgo plugin on a WordPress 7+ install.
2. Trigger a PHP error to seed an aggregated row:

   // In functions.php or a test plugin:
   trigger_error('Test undefined variable', E_USER_WARNING);

3. Navigate to WP Admin → Dashboard widget → click "Get AI Summary".
4. Verify the generated summary mentions PHP errors (type, message, count).
5. Navigate to WP Admin → Sybgo Reports → open the active report detail page → click "Generate AI Summary".
6. Verify the same error information appears in that summary.
7. Clear wp_sybgo_aggregated_events rows for event_type = 'php_error' and regenerate — verify no errors section appears and the rest of the summary is unchanged.

Affected Features & Quality Assurance Scope

• AI Summary generation (Dashboard_Widget::ajax_widget_ai_summary, Reports_Page::ajax_generate_ai_summary)
• Prompt composition (AI_Summarizer::build_prompt)
• Backward compatible: the new $aggregated_events parameter defaults to []; callers that don't pass it produce identical prompts.

Technical description

AI_Summarizer::generate_summary() gains an optional 4th parameter $aggregated_events (default []). When non-empty, build_prompt() appends a PHP Errors section listing up to 5 rows — the top-5 by occurrence count, which arrive pre-sorted from Aggregated_Event_Repository::get_rows_for_report().

Each row's dimensions JSON supplies the error level (e.g. warning, fatal_error) and the meta JSON supplies the message snippet and occurrence total.

Both AJAX call sites now fetch aggregated events before calling the summarizer:

• null for the active period — targets the report_id = 0 sentinel rows (unassigned current period).
• $report_id (int) for frozen reports.

See lib/docs/ai-transport.md (new "AI_Summarizer Prompt Composition" section) and lib/docs/report-lifecycle.md (updated AI Summary On-Demand flow).

New dependencies

None.

Risks

None identified. The parameter is optional and defaults to [], so any existing call site that is not updated continues to produce the same prompt without errors.

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

N/A

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

Unticked items justification

• "Ways to observe the implemented system": the AI prompt itself is the observable output. No dedicated logging added beyond what Logger::error already provides on transport failure.