security(api): bound public analytics response caches #370

Problem

On dborup/CoreScope master 1f423e0627976c961fb7a40f45016e817e582cc3, public analytics requests can create entries under client-selected filter/cache keys, and several maps in cmd/server/store.go still assign directly to keys such as rfCache[cacheKey], chanCache[cacheKey] and subpathCache[cacheKey]. TTL expiry does not itself cap the number of distinct keys retained before expiry. Invalid region/area inputs can also reach expensive analytics work before rejection.

Reference: nashmesh/CoreScope PR 18 (reference only). Related but different: #221 concerns regional node-query pool pressure, not these response-cache entry counts.

Requested change

• Inventory all public analytics response caches whose keys incorporate user-controlled filters or time-window variants, including neighbor graph and relay airtime where applicable in this fork.
• Give each affected map a fixed entry ceiling; remove expired entries first and use a deterministic, bounded eviction rule for remaining entries. Refreshing an existing key must not evict a different live entry.
• Reject excessively long filter values and unknown configured areas before cache/index/graph work, without rejecting legitimate region or area selections.
• Keep normal response schemas and valid-filter results unchanged.

Acceptance

• Tests exercise each affected cache family with more distinct keys than the ceiling and prove bounded size and correct refresh/eviction behavior.
• Handler tests prove invalid filters stop before expensive work, while valid filters keep working.
• Focused race tests and the full server test suite pass; no unbounded per-request work is added to cache insertion.

The repository diff demonstrates the unbounded-map pattern; this issue does not claim a measured production memory incident.