Expand page health monitoring to work for any website — platform agnostic

## Problem

A web performance audit isn't really about any single metric — page load, query time, plugin count. It's about reading the *fundamentals* of how an application uses its server: what's installed, what runs per request, where data lives, how that data ages. Every engineer doing a performance audit reaches for the same handful of signals first, regardless of the stack.

Today the dashboard captures page-level health (the symptom layer) and one server-side metric (autoload options). Everything else — the cause layer — still requires an engineer to SSH in, run platform-specific commands, query the database by hand, and write findings down. Each engagement starts from zero. The dashboard tells us a site is slow; it doesn't tell us *why*.

## The fundamentals we're missing

Every web application — WordPress, Laravel, Django, Node, anything custom — exposes the same categories of performance signal. The names differ; the shape doesn't.

| Category | What it tells you | WordPress shape | Generalizes to |
|---|---|---|---|
| Extension footprint | How much third-party code runs per request | Active/inactive plugin count | Composer packages, npm deps, Django apps, middleware stack |
| Per-request execution | What fires on every page render | WP Doctor hook count per page | Middleware count, event listeners, route handler chain |
| Storage shape | Where data lives and how it's structured | DB table sizes | Same across all relational stacks |
| Config-layer load | How much config is read on bootstrap | Autoload options size | env-var count, config cache size, settings table reads |
| Data aging | Whether transactional data is archived or hoarded | Order table size + oldest order age | Any transactional table — orders, events, audit logs, sessions |

These are the questions an engineer asks in the first 15 minutes of *any* audit. The dashboard should already have the answers when they open it.

## Why this matters now

Two motions converge here, and neither is possible without the fundamentals layer:

1. **The dashboard becomes a product, not a per-client report.** Today each audit is custom consulting — same questions, same commands, written up fresh each time. Once the fundamentals are captured automatically, the audit *starts from information*. The engineer's job shifts from data collection to interpretation.

2. **Cross-client intelligence becomes possible.** When the same signals are captured for every client in the same shape, patterns surface across the portfolio: which extension counts correlate with slow page health, which storage shapes predict future degradation, what archival cadence keeps transactional tables healthy. The dashboard stops being a per-site reporter and becomes a learning system.

## Expected outcome

The adapter pattern captures the five fundamental categories above, automatically, on a schedule, pushed to BigQuery.

WordPress is the first platform implementation (it's where the live engagement is). The collector interface is designed so the same five categories map to other platforms when the next engagement arrives. **Adding a new platform = implementing the five collectors for it, not rewriting the dashboard.**

## What changes downstream

- **Audit kickoff time drops from days to minutes.** The first conversation with a new client opens with diagnosis on the screen, not a list of commands the engineer needs to run.
- **The "WordPress performance" framing stops being WordPress-specific.** The same dashboard view answers Laravel, Django, custom-stack questions — because the categories are the same.
- **A new performance-audit engagement is a configuration, not a build.** Point the adapter at the new site; the dashboard fills in.

## Related
WordPress-specific metrics (plugin count, hook count, DB sizes) are tracked separately in: [coloredcow/performance-adapter-wp](https://github.com/ColoredCow/performance-adapter-wp/issues/11)