An admin runs a restore drill from the terminal's Resilience dialog with `r`, after a y/n, and reads the verdict there in the Backups page's words #8007

Intent: proving a backup restores is as near as taking one; today the Resilience dialog (src/tui/screens/resilience.ts) takes a snapshot (n) and levels the mirror (l) through src/actions/backups_now.ts, but the restore drill is only the Backups page's "Run a drill" button (backupsDrill in src/web/pages/backups.ts), which calls snapshotsOf(app).drill() itself.

Done looks like:

• [ ] src/actions/backups_now.ts gains drillNow(app, actor) in the shape of snapshotNow: a forge admin's only (not_found otherwise), no_store when there is nothing to drill, and an answer whose says is the page's sentence: "The drill restored green.", "The drill failed at <step>.", "The drill could not run: <error>." or "This forge has no snapshots to drill.".
• [ ] backupsDrill calls drillNow and flashes its says (danger tone unless green); the page answers exactly as today.
• [ ] In the dialog, an admin who is not busy sees r run a restore drill; r asks y/n as n and l do (the asking state), y runs drillNow with "Running a restore drill…" shown while it runs and the answer's says after; n/esc runs nothing.
• [ ] A new test/tui-resilience-drill.test.ts (in the shape of test/tui-resilience-now.test.ts) proves: r,y with a stubbed snapshot service shows the green sentence; r,n runs nothing; a non-admin is not offered r; a forge with no store says the no-snapshots sentence. It fails without the change.
• [ ] bun test test/tui-resilience-drill.test.ts test/tui-resilience-now.test.ts passes.

Files: src/actions/backups_now.ts, src/web/pages/backups.ts, src/tui/screens/resilience.ts, test/tui-resilience-drill.test.ts Risks: a real drill restores a snapshot and can take minutes; the test stubs snapshotsOf as the existing resilience tests do, and the dialog keeps busy set so a second key cannot queue a second drill. Brief: a builder who knows the terminal screens and snapshots.