One Admin page for status, accounts, and the audit log

Admins currently move between two admin surfaces — /status for instance state and /users for the account roster — and have no browser view of the audit log at all. Reading data/audit.log means logging in to the host or using the CLI, which is the wrong shape for “who changed this?” during a review or an incident.

Why

The audit log is the instance’s record of privileged actions. It should be readable by the people who are allowed to act on it, from the surface they already use, without turning the file into something a page can rewrite.

Scope

• One /admin page, instance-admin only, with tabs for Overview, Storage, Runners, Configuration, Accounts, and Audit log.
• Move the existing status tabs and the accounts roster onto that page; keep their handlers and templates as sections rather than copies.
• Redirect /status, /runners, and /users to the matching tab so old links and bookmarks still work.
• Add a read-only, paginated audit viewer: newest first, one record per row, with an older/newer pager. A line the reader cannot parse is skipped, not fatal.
• Read backwards from the end of the file so a page does not load the whole log.
• Refuse a symlinked or non-regular log at read time, as startup already does.
• Keep the admin surface out of the page-view metric, including the new audit tab.
• Update the top navigation, documentation, and tests.

Acceptance criteria

• /admin is a 404 for a signed-in non-admin and redirects an anonymous visitor to sign in; every tab is covered by a test.
• The audit tab shows the newest record first, pages back through the file, and reports the end of the log without counting records it never showed.
• /status?tab=storage, /runners, and /users land on the same content they did before.
• Audit detail is HTML-escaped and the tab is sent with Cache-Control: no-store.
• ./vole workflow run verify passes.