[Feature request] Password protection for public status pages (Implement ready)

## The gap

Status pages today are binary: fully private (team-only, requires login) or fully public (anyone with the URL). There's no option to share with a defined audience — customers, partners, internal staff — without making the page discoverable to anyone who finds the link.

## Proposed solution

Add an optional password to each status page in the existing create/edit form. Default off; opt-in per page.

When enabled:

- Public route returns `401 { requiresPassword: true }`; client renders a branded lock screen.
- Successful unlock sets an `HttpOnly`, `SameSite=Lax` cookie scoped to `/api/v1/status-page` (no re-prompt on reload).
- Brute-force protection: 10 attempts / 15 minutes per (page, IP), tracked as `sha256(ip + secret)` so raw IPs never reach Mongo.
- Admin JWTs bypass the gate (preview from the admin UI without re-typing).
- Changing the password invalidates existing unlock cookies via a `passwordVersion` counter.
- Admin list shows `Protected` / `Public` per page, so it's obvious at a glance.

### Screenshot & Video

Screenshot

Video

https://github.com/user-attachments/assets/7d0df30f-409d-4aaf-b917-9288689025dc

https://github.com/user-attachments/assets/f3978ded-82d9-4016-bbbc-b647acfef368

https://github.com/user-attachments/assets/eb218649-0f54-4160-b506-f97f2b7d2eda

### Relationship to other auth/permissions work

| Thread | Scope | Overlap |
|---|---|---|
| [#1689](https://github.com/bluewave-labs/Checkmate/issues/1689) — OIDC | App login for Checkmate users | None — different domain |
| [#2861](https://github.com/bluewave-labs/Checkmate/issues/2861) — Custom roles | Internal editor RBAC | None — different access axis (editors vs viewers) |
| [#3033](https://github.com/bluewave-labs/Checkmate/issues/3033) — HTTP basic auth | Auth at the monitored endpoint | None — different direction |
| [#3120](https://github.com/bluewave-labs/Checkmate/issues/3120) — Sensitive monitor data on status pages | Same status-page sensitivity space | Complementary — this gates the whole page; #3120 controlled which fields render |

This feature occupies an empty slot in the access-control matrix. It does not preempt OIDC or RBAC work.

## Alternatives considered

- IP allowlist — fails for mobile/remote viewers
- Signed links — breaks bookmarking, leaks via referrer
- OIDC for public viewers — too heavy for the "share with a small group" use case
- Reverse-proxy basic auth — works, but out-of-band from Checkmate's UI and branding

## Implementation readiness

A working implementation is ready https://github.com/bluewave-labs/Checkmate/pull/3662:

- **Server** — schema fields (`passwordHash`, `passwordVersion`), backfill migration, brute-force lockout repository (TTL-indexed), password service methods, unlock/lock routes behind the auth rate limiter, middleware with admin JWT bypass, OpenAPI registered.
- **Client** — lock screen, `AccessControlSection` in admin form, lock icon + `Access` column in admin list. All strings i18n'd. No hardcoded values.
- **Tests** — 1,166 unit tests passing; Coverage 90%+ on new modules.

Zero behavior change for existing pages. Feature defaults off.

Work is already under way in pull request #3662. Review its server, client, migration, repository, password-service, route, middleware, OpenAPI, and test changes first; the issue states that 1,166 unit tests pass and new-module coverage exceeds 90%. Done means the described password protection behavior is complete with no behavior change for existing pages.

Written by the indexing model from the issue text.