Describe the bug

CATS does not seem to pick up path-level common parameters — parameters defined at the path item level rather than inside individual operations. When a spec uses this pattern, CATS reports them as missing and sends the literal placeholder (e.g. {id}) in the URL instead of a fuzzed value.

To Reproduce

Run cats --contract api.json --server http://localhost:8080 with no additional headers or arguments, using a spec where path parameters are defined at the path item level:

"/v1/tenants/{tenant_id}/resources/{id}": {
  "parameters": [
    { "name": "tenant_id", "in": "path", "required": true, "schema": { "type": "string" } },
    { "name": "id",        "in": "path", "required": true, "schema": { "type": "integer" } }
  ],
  "get":    { "responses": { ... } },
  "put":    { "requestBody": { ... }, "responses": { ... } },
  "delete": { "responses": { ... } }
}

CATS logs the following and uses the unresolved placeholder in the request URL:

-> Path /v1/tenants/{tenant_id}/resources/{id}, http method GET: OpenAPI spec is missing definition for id

Expected behaviour

Per the OpenAPI spec, path-level parameters are inherited by all operations on that path (unless overridden at the operation level). CATS should merge pathItem.getParameters() with operation.getParameters() and fuzz those parameters the same way it does for operation-level ones.

Environment

Key           | Value
------------- | --------------------
OS Name       | Mac OS X
OS Version    | 26.3
OS Arch       | aarch64
Binary Type   | native
Cats Version  | 13.7.0
Cats Build    | 2026-01-29T20:59:40Z
Term Width    | 75
Term Type     | xterm-256color
Shell         | /bin/zsh

Additional context

Skimming FuzzingDataFactory, test data appears to be built exclusively from operation.getParameters() with no merge step for pathItem.getParameters(). This is a hypothesis — happy to be corrected if this is handled elsewhere or there's a flag that enables it.

Btw. the first results I am getting using cats are great - thanks so much! 🥳