Build and run the Elasticsearch + authorizations-on compose experiment for group D

Parent: #538
Related: #540 (baseline)

Background

#538's group D is 47 request-validation failures where routes 404 ("No static resource") on this
repo's compose deployment (docker/docker-compose.yml: rdbms secondary storage,
CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: false, UNPROTECTEDAPI: true) but responded on a
separately-tested Elasticsearch + authenticated deployment. #538 proposed measuring the correction —
switch secondary storage off rdbms, add Elasticsearch, turn on authorizations — and watch for one
side effect: the unsecured profile depends on UNPROTECTEDAPI: true with authorizations off to reach
the API with no credentials at all, so turning authorizations on may trade group D's 47 failures for
a much larger auth-shaped set instead of clearing them.

#540 recorded a real, reproducible baseline (578/1906 request-validation failures, 3 identical
nightly runs) but did not run this experiment: no Elasticsearch compose overlay exists in this
repo today (only docker/docker-compose.rdbms-unified-config.yml and
docker/docker-compose.rbac.yml), and building one plus wiring it into CI is nontrivial enough to
warrant its own issue rather than guessing at numbers nobody measured.

#540 also found the 404 surface on the current baseline is considerably larger than the original 47
— the whole agent-instance family 404s too (createAgentInstance, updateAgentInstance,
createAgentInstanceHistoryItem, searchAgentInstances, searchAgentInstanceHistory), not just
agent-definitions. Some of that 404 surface is unrelated to group D's cause: the group A
servers: override bug also 404s (restoreAsClusterAdmin, restore, changeClusterMode,
changeClusterModeAsClusterAdmin), and group C's seeded-path-param-resolves-to-missing-resource
bug does too (searchElementInstanceIncidents, searchUserTaskVariables, etc.). So this issue
should re-derive group D's actual scope against the current baseline, not assume the original
taxonomy still applies unchanged.

What to do

1. Add a compose overlay (alongside docker-compose.rdbms-unified-config.yml and
   docker-compose.rbac.yml) that runs camunda-oca against Elasticsearch instead of rdbms
   secondary storage, with CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: true.
2. Wire it into _oca-suite-run.yml / oca-ondemand-test.yml (same pattern as the existing
   camunda_image_tag-based compose-file selection) so it can be dispatched on demand without
   touching the nightly.
3. Dispatch a comparison run and measure, against #540's baseline (578/1906 request-validation,
   440/594 positive):
   • Does the corrected deployment clear the routes originally scoped to group D (and the broader
     404 set #540 found)?
   • Does it trade those for a larger auth-shaped failure set, per #538's warning? If so, that's
     itself the answer: the team is running two genuinely different deployment shapes, and the fix
     is a deployment dimension in the config layer (a scoped block in
     configs/camunda-oca/request-validation.json, a validator beside config.ts:227-249, selection
     via an env var alongside RV_PROFILE, threading through generate.ts:193-204, and guardrail
     tests) rather than picking one compose file as the baseline.
   • Re-check group J (backup operations) on Elasticsearch too — #540 found its originally-reported
     500/UNSUPPORTED_MESSAGE signature doesn't reproduce on rdbms at all (backups 404 there
     instead); confirm whether Elasticsearch resolves them to 200/403 as #538's manual probe found.
4. Re-derive which of the current baseline's 404s are genuinely group D (environmental,
   route-unregistered-under-rdbms) versus group A (servers: override) or group C (seeded path-param)
   showing up under the same HTTP status, so the numbers in #540/#538 stay accurate.

Acceptance

• A compose overlay + on-demand dispatch capability for the Elasticsearch + authorizations-on
  deployment shape exists and is documented.
• A measured comparison against #540's baseline, posted to this issue.
• A decision on group D (clears cleanly, or reveals a genuine two-deployment-shapes split needing the
  config-layer dimension described above), with the numbers behind it.
• Group J's Elasticsearch behavior confirmed one way or the other.

Start with docker/docker-compose.rdbms-unified-config.yml, docker/docker-compose.rbac.yml, and the compose-file selection in _oca-suite-run.yml and oca-ondemand-test.yml. Compare the dispatched Elasticsearch/authorizations-on run with #540's baseline, reclassifying group D, group A, group C, and group J outcomes. Done means the overlay and on-demand dispatch are documented, the comparison numbers are posted, and the deployment-shape decision is recorded.