Generated STATUS page — what exists, last-touched (fun, not urgent)

> _Filed by Claude (AI assistant) on @jmchilton's behalf — not personally authored._

**Priority: low / for fun.** Filed because it is a nice idea, not because anything depends on it. Do not let it jump the queue ahead of #248–#253.

## Idea

README's "Status" is one paragraph. A generated status surface — enumerating which Molds, Patterns, CLI pages, Schemas, and casts exist, with last-touched dates and cast up-to-date / stale counts — would make momentum and the provenance story tangible (useful incidentally for a grant narrative).

## Why generated, not hand-written

A hand-maintained STATUS.md rots — exactly the failure mode the project exists to avoid. The whole value is in the **generated** qualifier: derive it from content already in the repo (the same data the dashboard/validator already compute — content inventory, `_provenance.json` staleness vs. source hashes) via a `scripts/generate-*.ts` like the existing `generate-dashboard.ts` / `generate-index.ts`, and treat it as a generated artifact (don't hand-edit, regenerate).

## Sketch

- New `scripts/generate-status.ts` emitting a `STATUS.md` (or a site page) from existing collections + cast provenance.
- Counts: Molds, Patterns, CLI pages, Schemas, casts; stale-cast count from provenance hash drift.
- Last-touched from git or `revised` frontmatter.
- Wire into the same generation/CI path as the other generated docs.

## Constraints

- Must be generated and listed alongside the other generated files (don't hand-edit; regenerate).
- Reuse the dashboard/validator data path rather than a parallel inventory.
- Nice-to-have only — close as wontfix without guilt if it never rises in priority.

Effort: low. Surfaced during review of transient grant-proposal hardening notes.