[LeeroyHannigan]

What

The console metrics dashboard and its data feed now serve admin sessions only.

• GET /console/metrics redirects an IAM-user session to /console.
• GET /console/metrics-data answers an IAM-user session with HTTP 403 and {"__type":"AccessDeniedException","message":"Metrics are visible to admin users only"}. The handler returns the refusal before it reads the metrics store or the in-memory collector.
• The navigation bar shows the Metrics link to admins only. identity_label now returns the label together with whether the caller is an admin, so the 38 nav_bar call sites are unchanged.
• The page no longer sets const accountFilter for IAM users. The dashboard script never read that variable.

Admin sessions get the same payload as before, and the same page without the unused accountFilter variable.

The architecture guide, admin guide, getting started guide and security model now say the dashboard is admin only and covers every account. The upgrade manual has a v0.1.15 entry for the change, and the demo manual says to open the dashboard as the admin user. AGENTS.md's /metrics example now passes admin credentials, which that endpoint requires.

Merging with #704 and #734

This PR and #704 (console session revocation) conflict only in the imports of crates/server/src/console/pages/mod.rs: use crate::console::html; here against use crate::console::session::SessionCheck; there. Keeping both lines resolves it. On a trial merge, cargo test -p extenddb-server --lib console passed 20 tests, and tests/test_console_metrics_admin_only.py passed 7 against a SQLite build of the merged tree.

#734 (console account pages) adds a sentence to docs/manuals/10-security-model.md that says /console/metrics-data serves every console session the table metrics of every account until this PR merges. The two branches merge without a conflict, so git does not flag the sentence. Whichever PR merges second removes it: this PR if #734 is on main first, or #734 before it merges if this one is.

Why

/console/metrics-data checked only that the caller had a console session, then returned the rows of the metrics table. That table has no account column, and the store query filters on time, table name and metric only. So any IAM user who could log in to the console read the table names, index names, operations, request counts and latencies of every account. The account id the page set for IAM users stayed in the browser and did not limit what the server sent.

Reproduction on main's console code (f49c5f823), SQLite backend, 2026-11-01:

1. Create an account with an IAM user that has a console password. The account has no tables.
2. Log in as that user at /console/login and request /console/metrics-data.
3. The response is HTTP 200 and carries 18 distinct TableName values, all of them tables of other accounts on the server. ?window=LastHour and ?window=AllTime return the same 18 names.

The same steps on this branch return HTTP 403 with the body above and no table names, and /console/metrics returns a redirect to /console.

Testing done

New tests:

• crates/server/src/console/pages/metrics_pages_tests.rs, 5 tests. An IAM-user session gets 403 from the data feed with no table name, index name or operation in the body, and the store is not read. An admin gets both accounts' rows, their index dimension and the latency segments. An IAM-user session is redirected from the page. An admin gets the page without accountFilter. The nav bar has the Metrics link for an admin and not for an IAM user.
• tests/test_console_metrics_admin_only.py, 7 cases against a server. Two accounts each create a table and send it reads and writes. The fixture waits until the admin's feed shows both tables, which takes up to two flush intervals of 60 seconds. The IAM user of the second account then gets 403 and no table names from the feed under four query strings, a redirect from the page, and no Metrics link. The admin gets the page and both tables.

Commands, all on this branch:

• cargo +1.97.0 fmt --all -- --check: clean.
• cargo +1.97.0 clippy --locked -p extenddb-server --all-targets -- -D warnings: clean. With -W clippy::pedantic the crate has 499 warnings and none of them are in the changed files.
• cargo test --locked -p extenddb-server on Rust 1.99.0 and on 1.88.0: 242 passed on each.
• cargo check --locked --workspace --all-targets: clean.
• pytest against a SQLite debug build and against a PostgreSQL debug build: on each, tests/test_console*.py 42 passed, including the 7 new cases, and tests/test_metrics.py with tests/test_cross_account_isolation.py 23 passed.

Negative controls on the committed tree, each restored with git afterwards:

• Data feed check removed: the Rust 403 test fails, and the 4 Python feed cases fail with HTTP 200 and the first account's table in the body.
• Page check removed: the Rust redirect test fails.
• Metrics link shown to every session: the Rust nav bar test fails.
• main's console code: all 7 Python cases fail.

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test --workspace)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -- -W clippy::pedantic)
• I have added or updated tests for new functionality
• I have updated documentation if behavior changed
• Breaking changes are noted below (if any)
• If this changes the wire protocol, Storage trait, auth model, on-disk
  format, or public CLI surface, an RFC has been accepted or is linked
  below. Otherwise, an ADR captures the decision (link below).

CI ran the workspace tests on Rust 1.88.0 and on stable, and the integration suites on all four backends, and all of them passed. Clippy ran with -D warnings, without the pedantic group.

ADR / RFC: n/a

Breaking changes

IAM users lose the console metrics dashboard. The page redirects them to /console, the data feed returns HTTP 403, and the navigation bar no longer links it. Admin sessions and the admin-authenticated /metrics endpoint are unchanged.

Not covered by this change

• Per-account metrics (Metrics have no account dimension, so accounts with the same table name share rows, and failed requests record their raw table names #728). The metrics table has no account column on any of the four backends, and the collector and the flush worker carry no account dimension. A view of its own metrics for an IAM user needs that column, a migration on each backend, and the account carried from the request through the collector and the flush worker. Without the column, two accounts that use the same table name also share one row, so an admin sees their counts and latencies added together.
• The metrics table records the table name of a request that failed validation, so a CreateTable with an invalid name adds that name as a dimension value (Metrics have no account dimension, so accounts with the same table name share rows, and failed requests record their raw table names #728). After this change only admins read those values.
• The console's account, user, group and role detail pages show an IAM user another account's names when it requests them by that account's ID (Console: an IAM user can read any account's name and its IAM user, group and role names by account ID #724, fixed in fix: serve the console account pages to an IAM user for its own account only #734). This PR does not touch those pages.
• The README, the admin guide and the demo manual show curl .../metrics without credentials, which answers 401. docs: correct the quick start, monitoring commands, backend count and design index #668 corrects them.
• The navigation bar still links Settings and Cache for IAM users, and both pages answer them with 403, as on main.

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.