perf(dashboard): idle-gate the snapshot tick; cache static config; bound key-list refresh

The snapshot publisher broadcast to Clients.All on every ~1s tick forever, with
zero viewers. Each tick cost a session-registry snapshot and sort, a metrics
snapshot that copies dictionaries under the global metrics lock, a full rebuild
of EffectiveGatewayConfiguration, and a SQLite read of the API key table.

DashboardSnapshotHub now counts live connections into the singleton
DashboardSnapshotHubConnectionCounter (clamped at zero, since SignalR can call
OnDisconnectedAsync for a connection whose OnConnectedAsync faulted). The
publisher drives the snapshot enumerator by hand instead of await foreach: with
no connections it does not call MoveNextAsync at all, so the producing iterator
stays suspended at its yield and no snapshot is built — the gate removes the
build, not just the broadcast. It re-checks once a second, so the first viewer
resumes the tick within about one interval; that viewer is seeded immediately by
DashboardPageBase's synchronous GetSnapshot() and by the hub's OnConnectedAsync.

Two per-tick costs are bounded independently of the gate: the effective
configuration is startup-static (options are bound once at boot and never
reloaded), so it is built once and cached; and the API key summaries refresh at
most every 15s, since the list only changes when an operator creates, rotates,
or revokes a key. Only a successful refresh restarts the interval, so a failed
or timed-out read is still retried on the next tick with the previous summaries
left on screen.

docs/GatewayDashboardDesign.md

@@ -394,18 +394,6 @@ its lease expires. One session means one worker process backs every dashboard
 circuit; all access is serialised so the worker sees one in-flight command at a
 time. Tag reads go through `GatewaySession.SubscribeBulkAsync` / `ReadBulkAsync`.
 
-The advise set that backs those reads is capped at 256 tags (one browse page plus
-headroom) and evicted least-recently-read-first. Without the cap every tag any
-viewer ever inspected stayed advised on the single dashboard worker until the
-session faulted, so browsing a large galaxy accreted unbounded live MXAccess
-subscriptions — and the event churn they feed — on one x86 process. Reading a tag
-already in the set marks it most-recently-read; subscribing past the cap unadvises
-the oldest entries with `GatewaySession.UnsubscribeBulkAsync` in one batch before
-the new ones are advised. Tags read in the same call are never evicted to make
-room for each other. A failed unadvise does not fail the read: the tags are
-dropped from tracking anyway (they re-subscribe if read again), because the
-session-invalidation path already handles gateway/worker drift.
-
 The Alarms page does **not** use the dashboard session: alarm data comes from
 the gateway's always-on central monitor. `QueryAlarmsAsync` reads
 `IGatewayAlarmService.CurrentAlarms` — the monitor's in-process cache — so the