Remove the ten dead QUARKUS_TLS_DEFAULT_TRUST__STORE_* pairs from integration-tests/docker-compose.yml

[cuioss-oliver]

Summary

integration-tests/docker-compose.yml carries a QUARKUS_TLS_DEFAULT_TRUST__STORE_P12_PATH /
QUARKUS_TLS_DEFAULT_TRUST__STORE_P12_PASSWORD pair on ten gateway services. Every one of the
twenty lines is dead configuration. They predate PR #283 and were deliberately left untouched there;
this issue is the follow-up that decision routed them to.

Raised by CodeRabbit on PR #283
(thread). The spelling half of
that report is correct; its stated consequence — "the mounted trust material is omitted" — is not,
and the difference is why this is a cleanup rather than a bug.

The ten sites

Service	Lines
api-sheriff	340-341
api-sheriff-mtls	476-477
api-sheriff-cookie	572-573
api-sheriff-cookie-2	675-676
api-sheriff-ws-admission	762-763
api-sheriff-plain-mgmt	872-873
api-sheriff-passthrough-empty	973-974
api-sheriff-egress-verify-on	1220-1221
api-sheriff-egress-verify-off	1323-1324
api-sheriff-refresh	1425-1426

api-sheriff-no-certificate deliberately carries no such pair.

Why they are inert — two independent reasons

1. The spelling resolves to nothing. SmallRye Config maps each non-alphanumeric character to
exactly one underscore; a doubled __ encodes a quote. TRUST__STORE therefore decodes to the
malformed quarkus.tls.default.trust."store.p12.path, which matches no property. This rule is now
documented in doc/user/environment-variable-overrides.adoc (§ "Deriving the variable name") and
enforced by ServerTlsDeclarationGate, both landed in #283.

2. Nothing reads a default trust bucket. Even correctly spelled, the value would bind a bucket
no code verifies against:

• No gateway.yaml in the repo names a trust profile default. Every jwks.tls_profile and
  egress_tls.upstream_tls_profile across all nine config variants names benchmark-idp or
  it-upstream, each bound through a mounted .properties file with correct dotted spelling
  (benchmark-idp-trust.properties, it-upstream-trust.properties).
• Both trust resolvers do a named lookup only — JwksTrustProfileResolver:120 and
  EgressTrustProfileResolver:123 each call registry.get(tlsProfile). Neither calls
  getDefault().
• ResolvedServerTlsMaterial is the only production reader of registry.getDefault(), and it reads
  getKeyStoreOptions() — server key material, never trust material.

The mounted trust material is genuinely in effect, by two other mechanisms: every one of the ten
services sets -Djavax.net.ssl.trustStore=/app/certificates/localhost-truststore.p12 on the native
runner's command line (the JVM default TrustManager, which is what the confidential-client OIDC
engine uses), and every one loads benchmark-idp-trust.properties via QUARKUS_CONFIG_LOCATIONS,
binding the named profile to that same PKCS12. Integration tests pass at every HEAD of #283 with
these variables present-but-unresolvable.

The one real (benign) consequence

DefaultTrustSourceAudit — added in #283 — reads
registry.getDefault().map(TlsConfiguration::getTrustStoreOptions) purely to report it. With the
<default> bucket empty and javax.net.ssl.trustStore set, it logs WARN ApiSheriff-122 carrying
the ONLY_RAW_TIER_MOVED divergence sentence on all ten instances at boot. That is the audit
correctly reporting a real two-tier divergence; it is diagnostic output, not a trust gap. Whichever
disposition is chosen below should be checked against what that warning then says.

Proposed work

Preferred: delete all twenty lines. Correcting the spelling to QUARKUS_TLS_TRUST_STORE_* (the
unnamed <default> bucket) would populate a bucket nothing verifies against, and
doc/user/environment-variable-overrides.adoc records that this project's default bucket is
deliberately empty. Correcting to QUARKUS_TLS_DEFAULT_TRUST_STORE_* is worse — it binds a bucket
literally named default, which registry.getDefault() does not return at all.

Deletion is proposed rather than applied here because establishing the full effect requires a real
integration-test boot, which is why #283 declined to make the change on inference inside an unrelated
PR.

Acceptance

• All twenty lines removed from integration-tests/docker-compose.yml (or a documented reason to
  keep them recorded in the file).
• -Pintegration-tests green.
• The ApiSheriff-122 divergence warning re-checked against the resulting configuration.