fix(dashboard): enforce/document the advised-set cap honestly; cover handle-0 and oversize-read paths

docs/GatewayDashboardDesign.md

@@ -406,6 +406,19 @@ 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 cap is per-read, not absolute. A read may never evict a tag it is itself about
+to return, so one read of more distinct tags than the cap leaves the set that
+large; what the eviction pass guarantees is
+
+> after any read, the advise set holds at most `max(256, distinct tags in that read)`
+> tags.
+
+The overshoot is not sticky: the next read that subscribes anything measures the
+overflow against the oversized set and evicts the whole excess in one pass (a
+300-tag set plus one new tag evicts 45 and lands back at 256). A read that
+subscribes nothing new evicts nothing, but neither can it grow the set. A browse
+page requests far fewer tags than the cap, so in practice the set settles at 256.
+
 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