fix(openapi): don't emit a cookie apiKey as a silent header key

[rejifald]

What

stitch gen openapi's deriveAuth mapped every type: apiKey security scheme to a
core apiKey({ … }) call. But core's apiKey() only models two locations — a header
key (the default arm) or a query key; name locates the key in both. An in: cookie
apiKey scheme has no arm, so it fell into the default (header) arm and was emitted as a
header key: the wrong transport, silently, with no warning to the developer.

This guards the branch to in of header / query / undefined. A cookie scheme (or
any other unmodelled in) now falls through to the existing
"security scheme … not auto-mapped — set client.ts auth manually" warning, which is the
correct, honest behavior.

// before:  in: 'cookie'  →  apiKey({ name: "X-API-Key", value: env('API_KEY') })   // ❌ header key
// after:   in: 'cookie'  →  (no auth emitted) + warning "not auto-mapped"           // ✅

Test

Adds header / query / cookie coverage to gen-openapi.spec.ts. The cookie case asserts no
apiKey( call is emitted and the not-auto-mapped warning is present — it fails on main
and passes with the guard.

Context

Carved out of the big #470 contract-freeze sweep so this correctness fix can land and be
reviewed on its own, ahead of the mechanical rename bulk. In #470 the same hunk is
interleaved with a P7 only/tags widening and a scope→pool rename; only the
apiKey guard is included here.

Verification

pnpm --filter @stitchapi/openapi test (21 pass) + check:types clean; full pre-push
gate suite green.

🤖 Generated with Claude Code