[Findings] Tighten CACHE_GUARD / BATCH_GUARD bare-word leak

[AndresL230]

Summary

The CACHE_GUARD and BATCH_GUARD regexes in src/scanner/local-waste-detector.ts and src/ast/waste/{cache,batch}-detector.ts match the bare words cache and batch within an ±8-line source window. Any fixture (or real-world file) with those words in a docstring, comment, or unrelated identifier silently suppresses findings.

Evidence

• PR fix(detection): C1 PR-2 — tighten cache detector (closes part 2 of #83) #108 (C1 PR-2 cache tightening) was bitten by this — fixture docstrings with the word "cache" suppressed the test's positive case.
• PR fix(detection): C1 PR-3 — tighten batch detector (closes part 3 of #83) #109 (C1 PR-3 batch tightening) hit the same issue with "batch" in fixture comments.
• PR C1 PR-4: tighten rate_limit and residual batch FPs (closes #83) #111 (C1 PR-4) had to carefully avoid both words plus backoff/jitter/exponential/sleep( in all PR-4 fixtures.

What to do

Tighten both guards from bare-word matches to call-shape or assignment matches:

• CACHE_GUARD: require cache.get(, cache.set(, cacheKey:, useCache(, @cache, @cached, etc. — actual cache-API usage rather than the word.
• BATCH_GUARD: require batch.create(, .batches., bulk(, chunk(, messageBatches., flushQueue(, enqueue( — actual batching-API usage.

Add explicit positive/negative tests:

• Negative (must NOT suppress): docstring with the word "cache" or "batch", variable named batchSize, comment mentioning "this is a batch".
• Positive (must suppress): cache.get(key), await batch.create({...}).

Acceptance criteria

• CACHE_GUARD and BATCH_GUARD no longer match bare words; only call-shape / API-usage patterns.
• Existing C1 fixtures (PR-2 / PR-3 / PR-4) continue to behave correctly.
• New tests under src/test/c1-guard-tightening.test.ts covering both axes.
• No regression to per-type metrics in benchmark/baseline.json.

Depends on

None (cleanup PR).

Related

• [Findings] Calibrate the local waste detector (C1) #83 (C1) — closed via C1 PR-4: tighten rate_limit and residual batch FPs (closes #83) #111, but the guard-leak was a known gotcha left for a follow-up.