[loong10k]

Problem and repair

The custom authenticator skipped its configured strategy when multiple realms were configured but only one supported the token. This let AtLeastTwo accept a single successful password realm. Multi-configured-realm authentication now executes the configured strategy; truly single-configured-realm behavior follows Shiro's existing contract.

OnlyOne now rejects zero-success results at the authenticator layer and counts successful realm callbacks per invocation, including same-named realms. Both custom count strategies aggregate copies of principal collections and mutable credential collections, avoiding mutation of cached realm results across attempts. DefaultCredentialsMatcher evaluates its protected comparison exactly once. The hashed matcher synchronizes lazy cache initialization and its direct cache setter for safe publication. OnlyOne also explicitly rejects non-null realm results with null/empty principals using AuthenticationException, even if another realm succeeded.

Compatibility

• Multi-realm exceptions are now interpreted by the configured strategy; a specific realm LockedAccountException may become a general AuthenticationException. Truly single-realm exceptions are preserved.
• OnlyOne zero-success attempts emit failure rather than false success followed by Subject's empty-principal rejection.
• Non-idempotent credentialsMatch overrides are now invoked once.
• Public method signatures, production dependencies, coverage thresholds and the separate upstream-report archival patch are unchanged.

Validation

• Full offline JDK 17 and JDK 21 reactor clean verify: 40 tests, zero failures/errors/skips.
• Real Subject/Authenticator paths cover single/multiple configured realms, 0/1/2 successes, unsupported and dynamically changing realm support, exception behavior, shared concurrent strategy instances and cached aggregate isolation. Added boundary regressions reject one successful realm claiming two realm names, exercise reused cached AuthenticationInfo across requests and after OnlyOne rejection, and verify the Set credential snapshot branch with unmodifiable source sets.
• Credential tests cover comparison once, rejection, exception propagation, reset/principal isolation, fifth-attempt blocking (existing regression), and controlled concurrent lazy cache creation.
• Core line coverage is approximately 10%, still far below the existing 90% warning target; this is not comprehensive coverage.

Unresolved: retry counter atomicity — keep draft

Both retry matchers still have a confirmed first-insertion get/put race. This PR does NOT claim to fix atomic retry counting, cross-wrapper synchronization, distributed limits or generic cache TTL semantics. Shiro Cache has no CAS/atomic increment/remaining-TTL API. Blind per-attempt puts can refresh provider TTL; wrapper-local locks cannot coordinate other wrappers or JVMs. Controlled failing race probes and the design assessment are retained in the local task evidence and are not weakened into accepting assertions. A separately agreed provider/scoping contract is required for the counter repair.

The CI workflow still pins JWT issuer 6b1a4de65a12a155e98e957ea82e446ef6420b36; it does not validate the later c6edbf6 cache-collision fix.

Keep this PR in draft. No ready, approval or merge operation is part of this update.