/**
 * A cap for a `Map` keyed on something a producer chooses.
 *
 * Several reducers kept a session-lifetime `Map` keyed on a value taken straight off an event —
 * `raw.project`, `raw.tool`, a rule id — with no cap and no eviction. Because the bridge accepts a
 * `publish` envelope with an arbitrary `raw` and no origin check, a page the developer visited could
 * grow those maps one entry per message: `db.analyzeRuns` (issues/codex-security/19), the
 * `producers` registries in typecheck/lint/build (21), `visual.rules` (64), and the memory
 * reducer's `ownerNodeId` map (41).
 *
 * The existing bounds did not cover it. The `raw` clamp bounds ONE payload, not the number of
 * distinct keys, and the flood guard is per-fingerprint — so unique fingerprints, which the same
 * envelope chooses, step around it. That is the mechanism this repo already wrote down as
 * *"fingerprint is the flood bucket"*.
 *
 * Eviction is insertion-order: JS `Map` iterates in insertion order, so the first key is the oldest.
 * That matches the cap `db.reducer.ts` already applied to its query shapes, and it is the right
 * policy for these collections — the newest producer is the one a developer is looking at.
 */
/**
 * Trim `map` to at most `max` entries, dropping the oldest first.
 *
 * Returns the number of entries evicted, so a caller can report pressure rather than hiding it.
 */
export declare function capMap(map: Map<string, unknown>, max: number): number;
/**
 * Default ceiling for a producer-keyed registry.
 *
 * Far above what a real workspace produces — a large monorepo has tens of projects and a handful of
 * tools — and low enough that a forged stream cannot exhaust the process before the cap bites.
 */
export declare const MAX_PRODUCER_KEYS = 256;