Add parameter to constraint kind

Parent: #538

A coverage hole, not one of the 280. Found while tracing group F.

request-validation/scripts/generate.ts:609-623 builds its dedupe key like this:

const key = [s.method, s.path, s.type, s.target || '', s.bodyEncoding || 'json', bodyHash].join('|');

constraintKind is missing. For param-constraint-violation scenarios there is no body, so
bodyHash is '0', and target is just path.tenantId. Every violation kind for one parameter
therefore collapses into a single scenario, and only the first one generated survives.

paramConstraintViolations.ts:16-60 emits in order: pattern, length-min, length-max, enum. So
whichever comes first wins and the rest vanish.

How much this costs

I checked all 126 path params in the bundled spec. Every single one declares both a pattern and a
maxLength. So every one of them loses its length test today.

groupId is the only parameter with a surviving length test, and only because identifiers.yaml
deliberately gives it no pattern.

Fix

Add s.constraintKind || '' to the key.

What that does to the failure count

It restores about 126 tests, and the count goes up, on purpose.

Roughly 72 of them sit on string identifiers (tenantId, roleId, username, mappingRuleId,
clientId, name, id) and will fail, because the server enforces no path-param maxLength. That
is group F in the parent, and these 72 belong in the same upstream issue as more evidence.

The other 54 sit on numeric keys, where 266 characters of a also violates the numeric pattern. Those
should return 400 and pass, the same way their existing pattern tests already do. 92 of the path
pattern tests pass today.

You cannot suppress just the length cases

Worth stating so nobody spends an afternoon trying. excludeOperations[].scenarioKinds matches
s.type, and pattern and length-max share the type param-constraint-violation. constraintKind
exists on the scenario at model/types.ts:174, but nothing filters on it. Scoping an exclusion to one
constraint kind would need new config keys, which is not worth it for a stable number.

Tests

The dedupe block has no test at all today. That is how this went unnoticed. Add one asserting that
two constraint kinds on the same parameter both survive.

Check that tests/request-validation/coverage-applicability-wiring.test.ts:58 still passes; it reads
generate.ts as text.

Acceptance

• Regenerate and diff. About 126 tests added, nothing else changed.
• A new test covering the dedupe key.
• The new failures land in group F, not somewhere unexpected.

Dependencies

Shares no files with any other sub-issue. Land it after #540 so the other PRs stay interpretable
against a stable number. #SUB6 depends on this one.

Start in request-validation/scripts/generate.ts:609-623 and inspect how the dedupe key is built, then read paramConstraintViolations.ts:16-60 and model/types.ts:174. Add the dedupe test requested in the issue and run tests/request-validation/coverage-applicability-wiring.test.ts:58. Done means regeneration adds about 126 scenarios, failures remain in group F, and no unrelated changes appear.