BOURNE-3024: Sync upstream v6.5.1

[adhurjaty]

What this does

Merges the upstream v6.5.1 tag into main.

Alongside the upstream release itself, this recovers a set of upstream files that had gone missing
from main, and fixes a latent bug in ExecutionFlowsImportService (see resolution 2).

Where to look

Most of the diff is upstream fixture JSON — baseline realms and the import schema — which is safe to
skim. The Java changes are the review:

git diff origin/main...HEAD -- '*.java'

Within those, the substantive ones are AuthenticationFlowsImportService,
ExecutionFlowsImportService, ClientAuthorizationImportService and ImportAuthenticationFlowsIT.

Conflict resolutions

Most conflicts were in Java sources. The judgment calls:

1. UsedAuthenticationFlowWorkaroundFactory — kept deleted. Our "update flows in place" approach
   replaced upstream's delete-and-recreate path, so the class is unreferenced. Note this also drops
   upstream's InvalidImportException guard against changing a flow's built-in flag — deliberate, not
   a merge accident. Upstream's newer e88559a5 (setting postBrokerLoginFlowAlias to null
   mid-recreation) is moot for us; we never unbind.

2. ExecutionFlowsImportService — our updateExecutionFlows coexists with upstream's method,
   renamed updateBuiltInExecutionFlows. Both AuthenticationFlowRepository and upstream's newer
   keycloakProvider are now injected. main had dropped the former and lost the latter, which
   is the only reason it compiled — so this is a bug fix, not just a merge.

3. AuthenticationFlowsImportService — updateTopLevelFlow dispatches on
   existingAuthenticationFlow.isBuiltIn(). This is the heart of our update-instead-of-recreate
   behaviour and the highest-value thing to review.

4. ClientAuthorizationImportService — upstream's FGAP V2 resource-name fix (daf24b71) and our
   FGAP error handling converged on the same constructor change independently; kept one copy. The two
   fgapV2Active blocks live in different methods (updateClientAuthorizationSettings and
   updateAuthorization), which is intended.

5. ClientRepository — our stream-returning getAll/getAllIds over PaginationUtil, with
   upstream's single logger and without its now-dead private findAll.

6. Keycloak version now has one source of truth, and targets what we run. Our CircleCI
   build-arg pin was a second copy of the version alongside the Dockerfile default, and had drifted
   to 26.1.0 -- which is what made this a conflict. The pin is gone; CircleCI inherits the Dockerfile
   default. A follow-up commit then moves that single definition to 26.6.4, the version we run in
   production, rather than sitting on upstream's 26.5.5. The admin client stays at upstream's 26.0.8,
   since it has its own release line.

   That bump also drops activeByDefault from the pre-keycloak26-6 Maven profile. The profile
   excludes OrganizationRepository and OrganizationImportService from compilation and skips the
   passkey and organization ITs; leaving it on would silently disable organization support now that
   the default server version is 26.6.4. CI is unaffected either way -- it always passes -Pcoverage,
   which deactivates activeByDefault profiles.

Upstream code restored that main had lost

docs/SCHEMA_USAGE.md, keycloak-config-cli-import-schema.json,
OrganizationRepository.java.legacy, the baseline/* sets for 21.1.2, 22.0.5, 26.1.0, 26.4.0, 26.5.5
and 26.5.7, and some test fixtures. This accounts for most of the diff's size.

Verification

• Full unit suite passes
• Checkstyle, PMD and SpotBugs all clean — PMD was failing before this branch
• docker build succeeds and the resulting jar boots (fails only on absent keycloak.url, expected)
• ImportParallelImportIT passes against a real Keycloak container
• Audited the newly-inherited upstream commits for security regressions. No new exploitable
  vulnerability; YAML deserialization, the FGAP authorization change, auth-flow execution priority,
  new logging and dependency changes all checked clean. Two pre-existing findings in the
  default-disabled script-evaluation feature are written up separately — ask if you want the detail.
• Ran config on QA3 on this branch. All seems successful. Unsure how to test with high confidence there were no breakages.

Known issues

Integration tests need -Dkeycloak.version=<version> passed explicitly. Upstream's
maven-failsafe-plugin block is commented out, so ITs run under surefire and read the version from a
system property. Without it the container tag resolves to null and AbstractImportIT dies in its
static initialiser with NoClassDefFound — a harness quirk, not a regression.

Note on merging

Use a merge commit, not squash. Squashing would flatten the upstream history this brings in and
make the next sync harder to reason about.

Security audit

Claude artifact

🤖 Generated with Claude Code

[kermitapp]

Jira Issue: https://appfolio.atlassian.net/browse/BOURNE-3024