[shrsv]

Reworks Store's internal locking: instead of one RWMutex guarding the whole map, this change restructures the critical sections to batch Set+Delete under a shared lock scope, ahead of a batched-write API landing next.

No behavior change intended -- read/write semantics are preserved.

[livereviewbot]

LiveReview automated review

Scanned 3 changed files (+50/-8). No line-level findings -- the new applyLocked/SetMany helpers are correctly synchronized and the tests pass.

⚠️ Flagging anyway: internal/core.go is this service's most widely-depended-on file (imported transitively by every caller of Store), and this change alters the locking structure every mutating call goes through. A correctness regression here (e.g. a future edit to applyLocked that double-locks, or a deadlock between SetMany and a read-heavy caller) would silently affect every consumer at once, with no single line of this diff looking risky in isolation.

[livereviewbot]

Auto-approve policy evaluation

Stage	Result
Eligibility	✅ pass
LLM classification (refactor-only, confidence 9)	✅ pass
Findings	— none
Blast radius	❌ very high — central, widely-imported file, locking semantics changed
Risk score vs. threshold	❌ fails, driven entirely by blast radius

Verdict: BLOCKED at the risk stage. This is the case auto-approve has to get right on its own, without a finding to lean on: zero findings here does not mean zero risk. Blast radius alone -- how much of the system sits downstream of the changed file -- is enough to hold this for a human, even though nothing in the diff itself was flagged.

[livereviewbot]

Auto-approve policy verdict: BLOCKED (risk stage). Zero findings, but blast radius on a central shared file is very high -- the silent-landmine case.