fix(runtime): validate implicit 200 responses

[pmcelhaney]

Summary

• validate handler responses that omit status against the OpenAPI 200 response definition
• preserve explicit-status and default response behavior
• cover the regression through focused runtime tests and the shipped CLI journey
• document the implicit-success validation rule and release it with a runtime changeset

Original Prompt

Fix the confirmed bug where response validation is bypassed when a handler relies on the implicit HTTP 200 status. Create a dedicated branch and PR with a changeset.

Manual acceptance tests

• A handler that omits status and a required 200 response header returns its body with a response-type-error header.
• Supplying the required header removes the validation error without requiring status: 200.
• A handler with an explicit non-200 status is validated against that response definition.
• An OpenAPI default response still applies when the effective status has no explicit response entry.

Tasks

• Normalize response-spec selection to the effective HTTP status.
• Add unit, dispatcher, and black-box regression coverage.
• Update the response-validation FAQ and add a patch changeset.

Verification

• mise exec node@24 -- yarn build
• mise exec node@24 -- yarn workspace @counterfact/runtime test — 28 suites, 367 tests passed
• mise exec node@24 -- yarn typecheck
• mise exec node@24 -- yarn lint — passed with existing warnings only
• mise exec node@24 -- yarn test — 64 suites, 945 tests, 127 snapshots passed
• Generated-OpenAPI black-box journey passed; the remaining four journeys also passed across the full/targeted runs
• mise exec node@24 -- yarn test:packed-consumer
• mise exec node@24 -- yarn release:preflight
• git diff --check

Repository learning check

• Learning found: No
• Guidance updated: No
• Updated file(s): N/A
• Rationale: The defect is a localized status-default mismatch now captured by focused runtime and product-level regression tests; it did not reveal a new repository-wide contribution rule.