The kept front page is keyed on a one-row counter the database bumps when the shelf's data changes #6325

Replaces #6220. Pull #6258 keyed the kept page on a fingerprint that concatenated every app and every look on each request; three reviews refused it, because it grows without bound and was never measured. Measured 2026-10-26 on the live forge, signed out: / reports shelf;dur=40–61 ms, because dbKey(app) (src/actions/front.ts) moves on every session, heartbeat and log write.

Done:

• [ ] A migration adds a one-row table front_epoch(n). Triggers bump it on AFTER INSERT, AFTER DELETE, and AFTER UPDATE OF only the columns the shelf renders, on app, repo, front_pick and front_setting. On look, the triggers fire only WHEN NEW.env = 'production' AND NEW.kind = 'thumb'. dbKey reads SELECT n FROM front_epoch and nothing else. PAGE_MS and forgetFrontScores still bound and drop the page.
• [ ] Tests:

- A session insert and an issue_seq bump between two frontPage calls return the same object. This fails on main. - Archiving a repo, making an app private, and retaking a production thumb each give a new page. - With 2,000 apps, the key does not change size, and no app or look column is read for it.

• [ ] The key's cost shows in Server-Timing as key. The pull pastes /'s Server-Timing from its preview, twice.
• [ ] Run test/front*.test.ts and the migration tests, and bun x tsc --noEmit.

Files: a new file in src/core/migrations/, src/actions/front.ts, test/front-speed.test.ts.

Risk: a trigger on repo fires on every push. Keep its UPDATE OF list to the shelf's columns, never issue_seq or last_fetch_at.