Make zero local capacity consistent and evaluate byte-aware limits

[lan17]

Priority

P2 — Medium — local-memory hardening after the existing global entry bound, not a launch blocker by itself.

Current state

DialCache already has one lazily allocated LRU per instance, a validated global localMaxSize default of 10,000 entries, true cross-use-case LRU eviction, TTL expiry, and localMaxSize: 0 storage disablement. Applications can choose a conservative entry cap, disable process-local storage, or isolate workloads in separate DialCache instances.

Each stored entry still has weight 1, so retained native object size is not bounded by the entry count. One high-cardinality use case can also evict another use case's entries.

Current evidence:

• Global validated capacity
• Lazy global LRU and unit weighting
• Zero-cap storage path and unit-size writes

Concrete inconsistency

With localMaxSize: 0, no value is stored, but a configured local layer still resolves as enabled, reports a miss, and can activate instance-scoped single-flight. Storage is disabled while observability/control flow still describe an active permanent-miss local layer.

Recommended first scope — approval required

Make localMaxSize: 0 a true disabled process-local layer:

• Do not emit local request/miss events.
• Do not let a local-only policy activate process-scoped coalescing.
• Redis-enabled calls may still use process coalescing around their active remote layer.
• Add a bounded disabled reason only if existing reasons cannot describe the state cleanly.

Separate future decision

A caller-supplied estimated-weight function plus one global estimated-weight budget is the smallest plausible byte-aware extension. Exact heap-byte claims, per-use-case reservations, shared-pool allocation, and automatic object traversal are not approved and should not be bundled with the zero-cap fix.

Acceptance criteria

• Zero capacity has consistent storage, metrics, and coalescing behavior.
• Positive entry-count capacity retains current global LRU semantics.
• Any future weight API clearly defines oversized-item rejection and estimation failure.
• No claim of exact JavaScript heap measurement.
• Benchmark accounting overhead before enabling byte-aware weighting by default.