File real API issues found by generated tests #546

Parent: #538
Blocked by: #542, #543, #545

89 failures where the suite is doing its job. Each one is a place the server does not enforce
something the spec declares. The tests are right. The API is wrong.

File one upstream issue per group on camunda/camunda, then add knownIssues entries to
configs/camunda-oca/request-validation.json referencing them.

The convention

From configs/camunda-hub/request-validation.json: knownIssue.url points at the upstream issue, and
knownIssue.tracker points at the api-test-generator issue, which here is the parent.
tests/codegen/known-issue-summary-consistency.test.ts enforces that entries sharing a URL share a
summary.

These stay red

knownIssues is reporting metadata. It does not drop tests. So every one of these 89 keeps failing
until the API changes, and the nightly from #SUB0 keeps failing with them.

That is the intended outcome, agreed up front: visible in the report and labelled with a tracking
issue, rather than buried in an exclusion list where nobody would ever look at them again. Anyone
tempted to "fix" the red nightly by converting these to excludeOperations should read the parent
first.

The groups

F, path-param pattern and maxLength not enforced. 24 failures, plus roughly 72 more once #SUB5
lands. RoleId, TenantId, Username and MappingRuleId declare a pattern. GroupId declares
maxLength: 256. The server enforces none of them on path params. POST /v2/roles/!/users/search
returns 200 with an empty page. GET /v2/roles/! returns 404. GET /v2/roles/<266 a's> returns 404.
Never 400.

Expect pushback on this one. A reviewer can reasonably argue that 404 is fine for an unmatchable path
segment. If upstream declines, the fallback is an excludeOperations entry scoped to
param-constraint-violation, with the argument written into reason so the next person does not
relitigate it.

G, page.limit: 0 accepted. 41 failures. All four oneOf branches declare minimum: 1, so 0
violates every one. {"limit":0} returns 200 and {"limit":-99} returns 400 on both deployments.
The server looks like it only checks limit < 0.

H, operationReference minimum not enforced. 12 failures. The schema declares "type": "integer", "format": "int64", "minimum": 1, and the description spells it out: "Must be > 0 if provided." The
server takes 0 and -99 on all six process-instance batch operations.

I, blank and whitespace tenantId accepted. 8 failures. publishMessage, broadcastSignal and
getProcessDefinitionInstanceVersionStatistics all accept "" and "\n". Both fields resolve
through allOf to TenantId, which declares minLength: 1 and
pattern: ^(<default>|[\w\.\-]{1,31})$.

J, 500 on backup operations. 2 failures. "Unexpected error occurred between gateway and broker (code: UNSUPPORTED_MESSAGE)". Check #SUB0B first. If these vanish on Elasticsearch they are
environmental and belong with group D, so drop this filing.

K, undecodable cursor accepted. 2 failures. searchProcessDefinitionVariableNames returns 200 for
a cursor that 40 other endpoints correctly reject with 400. An endpoint-specific inconsistency.

Also file, from group B

Two more, both from #541's analysis:

• OffsetPagination.limit is missing maximum: 10000, which the other three oneOf branches all
  declare. It looks like a plain omission. If upstream adds it, the scenarios #SUB1 drops become
  correct and can come back.
• {"page":{"limit":10001}} returns 500 on Elasticsearch with "The search server was unable to process the request", the max_result_window limit, for a request the contract permits.

Acceptance

• One upstream issue per group, linked from knownIssue.url.
• knownIssues entries in configs/camunda-oca/request-validation.json, all with tracker set to
  the parent.
• tests/codegen/known-issue-summary-consistency.test.ts green.
• The nightly step summary shows each remaining failure group with its tracking link.

Dependencies

Last in the sequence. Needs #545 merged, so the group F entry covers its added failures as one thing
rather than two. Touches configs/camunda-oca/request-validation.json after #542 and #543.