security(api): limit expensive public memory diagnostics #371

Problem

GET /api/perf?mem=1 is public on dborup/CoreScope master 1f423e0627976c961fb7a40f45016e817e582cc3. It calls GetStoreMemoryBreakdown(), an opt-in traversal of the in-memory transmission/observation store. The normal /api/perf path is cheap, but overlapping or repeated mem=1 requests are not currently admitted through a concurrency or cooldown gate and can multiply this expensive work.

Reference: nashmesh/CoreScope PR 19 (reference only).

Requested change

• Limit store-backed memory diagnostics to one active scan per server process and apply a short cooldown after completion, or provide an equivalent early admission boundary.
• Reject excess requests before taking the packet-store read lock; return a clear retry response (for example 429 with Retry-After).
• Leave ordinary /api/perf and storeless behavior unchanged. Keep admission state process-local unless a multi-instance requirement is demonstrated.

Acceptance

• Deterministic tests cover concurrent requests, immediate repeats, completion/release, the cooldown boundary and response headers.
• Race tests pass, and the expensive store traversal is not entered for rejected requests.
• Full server tests pass and existing /api/perf consumers remain compatible.

This is a resource-safety issue identified in the code; no production abuse is asserted.