perf(cache): cache version-manager map grows unbounded with tables × scopes

[EricAndrechek]

Area: cache — scalability · found via TODO sweep

Issue: the in-memory cache version map keys on table (and scope) and is never bounded or evicted. The code's own TODO flags it: "potentially could be bad/dangerous with a low amount of RAM AND a TON of tables/scopes per table." Under high table/scope cardinality this grows unbounded.

Severity: low today (bounded table set, single-tenant); a real memory risk once scopes/multi-tenant land or table cardinality grows.

Scope: bound the version map (size cap / eviction), or move versions to L2 for distributed/high-cardinality deployments. Coordinate with tiered-cache #86 and the scope/multi-tenant story #214/#235.

---

Found via codebase TODO sweep, 2026-06-04 (internal/cache/version_manager.go:12).

[EricAndrechek]

#621 fixes the two unbounded-growth paths this issue names for the in-process cache: the version map no longer keeps every tenant ever served (a departed tenant's whole index is dropped, not just bumped), and a table bump no longer accumulates old scope versions underneath it.

Narrowing what's left open here: per-table scope cardinality is still uncapped. Today scope is always empty (#235), so this doesn't bite yet, but once #235 populates it, a table with many distinct scopes written between whole-table writes will grow that table's scope map without a cap or eviction — #621 only bounds growth across bumps and tenant departures, not cardinality within a live tenant/table.

Trigger for follow-up: when #235 lands scope population, internal/cache.VersionManager's per-table scope map needs a size cap or eviction policy. Leaving this issue open for that; #621's PR body has the detail under "Deliberately left to later PRs".