feat(Health): Site Health board — check registry + security checks (#41 phase 1)

[parisek]

Implements phase 1 of #41 per the design refinement comment (code-first configuration, read-only board).

What

• New Parisek\TimberKit\Health\ sub-namespace: HealthCheck interface (declares effect/config/both verification method), Result value object (static constructors only — invalid status unrepresentable), CheckRegistry (unique ids, throws on collision), SiteHealthAdapter (the only Site Health touchpoint).
• Five security checks: XML-RPC disabled, WP version hidden, author sitemap disabled, file editing disabled (config), REST users endpoint restricted (anonymous loopback probe).
• StarterBase::$site_health flag, default false (feature-flag doctrine). Wiring: defaults → health_checks() Base.php override (primary customization path, visible in project diffs) → timber_kit_health_checks filter (uniform low-level hook) → adapter.

Read-only by design

The board never writes: no options page, no DB toggles, no remediation buttons. Expected state lives versioned in code; Site Health reports drift. "Actions" hints point to code fixes.

Testing on a real project

In the project Base class set protected bool $site_health = true;, then open Tools → Site Health → Status. Five "Security" badged entries appear; the REST users check performs a loopback request (falls back to recommended with an explanation when loopbacks are blocked).

Follow-ups (tracked in #41)

• timber-kit self-diagnostics category (version currency, deprecated API usage, flag inventory via debug_information)
• CLI adapter (wp timber-kit health) for CI gates + fleet sweeps
• Migrate the two existing ad-hoc Site Health tests (warn_duplicate_security_headers, resizer_format_health) onto the registry
• Remaining categories (caching / SEO / mail / performance / a11y)

Closes nothing — #41 stays open as the tracking issue.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BJHq7Gez1NRq46Q7dwvra6