Add a self-monitoring check for the results store.

Problem/Motivation

The results store (#3608513: Add results store and trends) has moving parts that can silently stop: cron collection can go quiet, and the retention purge can fail while collection succeeds — in which case the tables grow without bound and nobody is told. A diagnosis module whose own storage rots undiagnosed would be an embarrassment; Site Doctor should check itself with the same machinery it points at everything else.

Steps to reproduce

Break the purge (e.g. set an invalid retention value in a hook) and let cron run for months: resolved-finding rows accumulate past every horizon with no signal anywhere.

Proposed resolution

An entropy-category check inspecting Site Doctor's own tables against expectations derived from the retention settings:

• Resolved finding rows older than the configured horizon exist → the purge is not running (Warning: it means cron reaches collection but not cleanup, or errors are being swallowed).
• Row counts wildly out of proportion to the check roster and run cadence → something is churning abnormally (Info, with the counts as evidence).
• Collection staleness itself stays where it already lives (status report + report page) — this check does not duplicate it.

All thresholds derive from the site's own retention.* configuration — no new settings.

Recipe: plugin in src/Plugin/SiteDoctor/Check/, kernel test in tests/src/Kernel/Check/ extending CheckKernelTestBase, fixtures in both directions (aged unpurged rows / healthy tables). See CONTRIBUTING.md.

Remaining tasks

• Agree severities (proposed: unpurged-past-horizon Warning, proportion anomaly Info).
• Implement + kernel tests.

User interface changes

None beyond new rows in existing check output.

API changes

None — one new check plugin.

Data model changes

None — reads the existing store tables.