fix: cast OAS3 schema-typed parameters at runtime

[Copilot]

Summary

OAS3 places parameter types under parameter.schema.type rather than the OAS2 top-level parameter.type. The dispatcher's parameterTypes() only read the OAS2 field, so path/query/header parameters declared OAS3-style were never cast — e.g. $.path.petId remained "1" (string) instead of 1 (number).

Fix: one-line fallback in Dispatcher.parameterTypes():

// Before
const type = parameter?.type;

// After
const type = parameter?.type ?? parameter?.schema?.type;

Test: new dispatcher test mirrors the existing OAS2 casting test but uses schema: { type: "integer" } etc. to cover the OAS3 path end-to-end.

Original Prompt

When a parameter is not a string per the OpenAPI spec the server should perform type conversions as necessary.

For example when GET /pet/1 is called, $.path.petId should be a number not a string.

Manual acceptance tests

• GET /pet/1 where petId is declared as OAS3 schema: { type: "integer" } — $.path.petId is the number 1, not the string "1"
• GET /pets?limit=10 where limit is declared as OAS3 schema: { type: "integer" } — $.query.limit is the number 10, not "10"
• A header declared schema: { type: "boolean" } with raw value "true" arrives as the boolean true in the handler
• OAS2-style type: "integer" path/query/header parameters still cast correctly (regression)
• String parameters remain strings under both OAS2 and OAS3 declaration styles

Tasks

• Fixed Dispatcher.parameterTypes() in src/server/dispatcher.ts to fall back to parameter.schema?.type when parameter.type is absent
• Added a new test in test/server/dispatcher.test.ts covering OAS3 schema-typed path, query, and header parameter casting
• Added a patch changeset