docs(rules): keep Java composition guidance in modern-java only

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

shared/rules/java/references/architecture-and-apis.md

@@ -7,5 +7,5 @@ Apply these rules when designing public APIs, service boundaries, or application
 * Authorize the specific resource and operation where data is accessed or changed. Preserve ownership and tenant scope across alternate paths and background work.
 * Bound payloads, page sizes, query complexity, and operation cost. Use pagination or streaming for potentially large results.
 * Keep domain decisions separate from transport, persistence, and framework wiring. Make dependencies explicit; use dependency injection for real lifecycle or substitution needs.
-* Prefer composition and small contracts at real boundaries. Avoid service locators, broad base classes, reflection, and wrappers without a concrete purpose.
+* Use small contracts at real boundaries. Avoid service locators.
 * Preserve existing API and serialization behavior unless the task requires a change. Treat changes to nullability, ordering, exception types, and collection mutability as compatibility changes.

shared/rules/java/references/modern-java.md

@@ -6,7 +6,7 @@ Apply these rules when editing Java syntax, class structure, and everyday code o
 * Prefer direct control flow and descriptive domain names. Use streams when they clarify a transformation; loops are often clearer for stateful work or error handling.
 * Use local `var` only when the initializer makes the type obvious. Keep public contracts explicitly typed.
 * Use records for transparent immutable carriers and sealed types for genuinely closed variants when the target release supports them. Do not force them onto mutable entities or framework-managed types.
-* Prefer composition and focused classes over inheritance, reflection, global mutable state, or speculative interfaces.
+* Prefer composition and focused classes over inheritance, broad base classes, reflection, wrappers, global mutable state, or speculative interfaces.
 * Make ownership, mutation, and side effects visible. Use `final` where it clarifies invariants; do not add it mechanically to every local variable.
 * Prefer supported `java.time` APIs and standard library facilities over obsolete APIs or custom helpers when they fit the contract.
 * Remove dead code. Add comments only for non-obvious decisions or public contracts that code cannot express clearly.