Clean, well-bounded fix for a painful real-world problem. The design is sound: verify once per repository per session, only on the deny path, only for auto-discovered (not user-provided) prefixes. The bounded cost (at most one HEAD per repo per session) preserves the round-trip savings RRF provides in the normal case.

Thread safety — Verified: the volatile prefixTree field + AtomicBoolean CAS + synchronized(cachedPrefixes) block correctly ensures exactly one verification per repository, with concurrent denied-path threads waiting for the verdict rather than returning stale denials. The synchronized block around the network peek() is the right trade-off — without it, concurrent threads could observe the original (broken) tree and return false denials while verification is in flight. Since this happens at most once per repo per session, the lock duration is acceptable.

API compatibility — The constructor gained a TransporterProvider parameter. Since the class is in internal.impl and uses @Inject, DI consumers (the primary path) are unaffected. Both RepositorySystemSupplier variants (mvn3/mvn4) are updated. The PR correctly notes Maven core wiring needs the same update when upgrading resolver. ✓

Tests — Thorough coverage of all cases: core scenario (broken prefixes dropped), repository-wide propagation, bounded peek cost, accepted-path passthrough, disabled config, offline mode, and user-provided authority. Using the actual leaked Jenkins prefixes file as test data ties the tests directly to the reported incident.

One suggestion: consider adding a test for the noInputOutcome=false interaction. When broken prefixes are dropped, noInputResult() delegates to the noInputOutcome config (default true/accept). If a user has explicitly set noInputOutcome=false (block when no input), the broken file is detected and dropped, but the path is still denied — the build still fails, just with a different diagnostic. This is arguably correct behavior (the user asked for strict filtering), but a test documenting this interaction would prevent future confusion:

@Test
void brokenPrefixesDroppedButNoInputOutcomeFalseStillDenies() throws Exception {
    session.setConfigProperty(
            PrefixesRemoteRepositoryFilterSource.CONFIG_PROP_NO_INPUT_OUTCOME, "false");
    RemoteRepositoryFilter filter = subject.getRemoteRepositoryFilter(session);
    assertNotNull(filter);

    // prefixes are broken and dropped, but noInputOutcome=false means denial
    assertFalse(filter.acceptArtifact(remoteRepository, jenkinsArtifact).isAccepted());
    // verification still happened (peek was called)
    verify(transporter, times(1)).peek(any(PeekTask.class));
}

CI — Matrix still pending (just opened). One pre-existing flaky test (JettyTransporterTest.testGet_HTTP3 on Windows) is unrelated.

Reviewed with oss-code-reviewer on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

Thanks for adding the noInputOutcome=false interaction test — it looks correct: verification still happens (one peek), the broken file is detected and dropped, but strict filtering honors the user's explicit config. Clean commit.

Re CI: noted that master is red from #1970's awaitility changes — this PR's test-only commit 3 is unaffected. Will re-check once #1977/#1978 lands and you rebase.

Reviewed with oss-code-reviewer on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.