[Feature] Add Monitor page to Canopy

## Summary
Introduce a **Monitor** page in the Canopy web console that surfaces BanyanDB cluster/runtime health, key metrics, and node status — giving operators a single place to observe the state of the database from the UI.

## Motivation
Today Canopy focuses on schema CRUD and ad-hoc query (Groups, Streams, Measures, Traces, IndexRules, Properties, TopN pipelines). There is no dedicated surface for **runtime/cluster observability**. Operators currently have to rely on:
- raw BanyanDB HTTP endpoints,
- external Prometheus/Grafana dashboards,
- log scraping.

A first-class Monitor page in Canopy lowers the operational bar and complements the existing schema/query UI.

## Goals
- A new top-level **Monitor** entry in the Canopy sidebar.
- Pulls data from BanyanDB's existing observability surface (HTTP API + Prometheus metrics where applicable).
- Renders key health signals and recent trends.
- Role-gated: available to `admin` (and possibly `readonly`).

## Scope (suggested sections — refine during design)
1. **Cluster overview** — node list, liveness, role (liaison/data), version, uptime.
2. **Shard / group status** — per-group shard health, replica state, hot-node distribution (reuses concepts from existing BYDB-Replica work).
3. **Storage metrics** — disk usage per node/path, segment counts, `sidx`/inverted-index sizes, write amplification (sourced from `docs/operation/observability/metrics.md`).
4. **Query metrics** — QPS, p50/p95/p99 latencies, error rate, slow-query top-N (mirrors the existing `banyandb_*` metrics).
5. **Recent events / alerts** — last N warnings/errors from BanyanDB (if surfaced via API) and any active TopN pipeline anomalies.
6. **Trace pipeline status** — if Trace Pipeline (per #13634) is enabled, surface its stage/throughput.

## Tasks
1. **Research** — enumerate the BanyanDB HTTP endpoints and metrics that can power each Monitor section; identify gaps that require new backend API.
2. **Design doc** — proposed layout under `canopy/docs/monitor-design.md`; data-fetching strategy (BFF proxy + caching vs. direct from SPA); refresh interval; empty/error/loading states.
3. **PoC** — implement the page shell with **Cluster overview** + **Storage metrics** end-to-end (server proxy + web page) using existing BanyanDB endpoints; stub the other sections behind a feature flag.
4. **Tests** — Vitest tests for new BFF proxy routes; component tests for the page; e2e smoke under `canopy/e2e/`.
5. **Docs** — update `canopy/README.md` (sidebar change) and add `canopy/docs/monitor-design.md`.

## Acceptance Criteria
- New `/monitor` route accessible from the sidebar.
- Cluster overview + storage metrics render real data from a running BanyanDB.
- Loading / empty / error states handled.
- Bounded refresh interval (default 10s, configurable).
- Role enforcement: `admin` only by default (configurable to allow `readonly`).
- Unit + e2e tests pass.
- Docs updated.

## Out of Scope
- Custom alerting rules / notification channels.
- Long-term metrics storage (rely on Prometheus).
- Replacing the existing SkyWalking OAP observability dashboards — this page is a lightweight in-product view, not a Grafana replacement.

Start by reviewing docs/operation/observability/metrics.md and enumerating the BanyanDB HTTP endpoints and metrics for the proposed sections. Capture the layout and data-fetching approach in canopy/docs/monitor-design.md, then inspect the existing Canopy sidebar and test locations under canopy/e2e/. Done means a scoped design and implementation plan covering the /monitor route, loading/error states, refresh behavior, role enforcement, and tests.

Written by the indexing model from the issue text.