Clarify non-capturing lambda review guidance

Author: trask

.github/agents/code-review-and-fix.agent.md

@@ -304,9 +304,9 @@ Auto-fix boundaries:
 - Never change:
   - literal type suffixes (e.g., `200` → `200L` or vice-versa) — Java widens
     automatically; both forms compile identically and the change is noise
-  - non-capturing lambdas or method references as unnecessary allocations; do not flag or
-    fix these, because on modern JDKs these are typically cached at the call site rather
-    than allocated on every invocation
+  - non-capturing lambdas or method references as allocation issues; do not flag,
+    fix, or justify changes to these as per-call allocations. On HotSpot /
+    OpenJDK 8+, these are cached at the call site.
 
 Output content rules:
 

.github/agents/code-review.agent.md

@@ -91,9 +91,8 @@ For each file in scope:
    - PR mode: changed lines only
    - File/directory mode: all lines
 4. Apply checklist rules (below) and insert comments above offending lines.
-5. Do not flag a non-capturing lambda or method reference as an unnecessary allocation,
-   because on modern JDKs these are typically cached at the call site rather than
-   allocated on every invocation.
+5. Do not flag a non-capturing lambda or method reference as an allocation issue.
+   On HotSpot / OpenJDK 8+, these are cached at the call site.
 6. Flag a missing version-boundary comment on a single-class `hasClassesNamed(...)`
    check in `classLoaderMatcher()` only after validating the stated boundary from
    repository or upstream evidence. Use `// added in X.Y` for a pure lower bound.

.github/agents/knowledge/general-rules.md

@@ -75,6 +75,8 @@ Read and apply `docs/contributing/style-guide.md`.
 Do not flag the following patterns (common false positives):
 
 - FQCN is acceptable when class-name collision makes import impossible.
+- Do not claim that a Java non-capturing lambda or method reference allocates per
+  call. On HotSpot / OpenJDK 8+, these are cached at the call site.
 
 ## [Style] Visibility modifiers