feat: show transported region scopes in repeater sidebar

[syssi]

When clicking a repeater node, the detail sidebar currently shows relay stats (last relayed, relay count, traffic share, bridge score) but gives no indication of which region scopes the repeater has been transporting.

Proposed behaviour

Add a "Transported scopes" row to the repeater stats table in the node detail sidebar. The list is derived passively by inspecting the scope_name field of all transmissions the repeater appears in as a path hop (byPathHop index). No user action or active probing required.

Why this is useful

A repeater's geographic relay footprint is not always obvious from its location alone. Knowing which region scopes transited through a repeater helps operators understand cross-region bridging behaviour, diagnose unexpected scope bleed, and plan coverage. The traffic-share and bridge-score metrics already hint at structural importance; the scope list makes that concrete.

Implementation sketch

The data is almost entirely available in-memory already:

1. Add ScopeName string to StoreTx and populate it from transmissions.scope_name during Load (the column is guarded by the existing hasScopeName flag).
2. In computeRepeaterRelayInfoMap (repeater_enrich_bulk.go), accumulate a deduplicated []string of scope names while walking byPathHop entries. Store as TransportedScopes []string on RepeaterRelayInfo.
3. Expose the field via handleNodeDetail alongside the existing relay_count_1h, relay_count_24h fields.
4. Render a new table row in nodes.js (the repeater stats block around line 634), visible only when the array is non-empty.

Estimated effort: small (~50 lines Go + ~15 lines JS). No new endpoint or DB query at request time needed.

Fallback

If hasScopeName is false (older schema), the field is simply absent and the row is hidden, so there is no regression for older deployments.

[Kpa-clawbot]

Severity: P3 — feature add, no operator pain, purely additive UI surface.

Claim: confirmed. Repeater sidebar exposes relay/bridge stats but no scope-list. Data is already in-store via transmissions.scope_name (guarded by hasScopeName flag at cmd/server/store.go:166-177) and walkable through byPathHop.

Code today: StoreTx (cmd/server/store.go:32) carries no ScopeName field today; repeater_enrich_bulk.go:1-266 builds RepeaterRelayInfo from byPathHop walks without scope accumulation. Frontend repeater stats block lives in public/nodes.js (~line 634 area).

Findings:

• (carmack): Adding ScopeName string to StoreTx costs ~16B per packet × ~65K capacity = ~1MB steady-state — acceptable. Dedup the scope set per-repeater using a small map[string]struct{} inside the byPathHop loop, NOT a per-tx slice scan; the latter is O(n²) on busy bridges.
• (tufte): UI row should hide when empty AND when a repeater transports only one scope (its own) — that's the no-information case and clutters the panel. Show only when ≥2 distinct scopes (real cross-region bridging).
• (house): Verify scope_name is actually populated end-to-end on prod; if observer pipeline leaves it NULL for self-published packets, "transported" semantics will be subtly wrong (the repeater's own region won't appear).

Fix path: per issue body's 4-step sketch. Add ScopeName to StoreTx, populate in Load, accumulate TransportedScopes []string in computeRepeaterRelayInfoMap, expose via handleNodeDetail, render row in public/nodes.js only when len≥2. Effort: S.

Dup check: searched "transported scopes", "repeater scope", "scope sidebar" — none.

PR status: PR #1752 already open (ArcanConsulting, 2026-06-19 13:00 UTC). Route to pr-polish, not new fix chain.

Triage verdict: ready-to-fix (covered by open PR #1752)