fix: Cloudflare keyed header/cookie conditions emit invalid wirefilter

[gfargo]

Fixes #269

Summary

A keyed header or cookie condition (e.g. "match this specific header/cookie name") compiled to wirefilter Cloudflare's real API rejects — found while researching #263's query fix, which surfaced that the existing header/cookie key-scoping code shares (and in cookie's case, exceeds) the same construct problem query had.

• header: compiled to http.request.headers["key"] eq "value". http.request.headers is Map<Array<String>> — indexing it yields an Array, and comparing an Array against a String literal via eq is a type mismatch. Verified against Cloudflare's own "Require specific headers" WAF guide, which uses any(http.request.headers["key"][*] eq "value") for exactly this case.
• cookie: worse — compiled to http.cookie["key"] eq "value", but http.cookie is a scalar String (the whole Cookie header), not a Map at all. Verified Cloudflare has a separate http.request.cookies field that is the right Map<Array<String>> shape (same any(...) idiom), so the fix points the keyed case at that field instead, leaving the scalar http.cookie untouched for the unkeyed case.
• Header key casing: also lowercases the header key now — Cloudflare's docs state header map keys are always lowercase, so a condition built with key: 'Content-Type' would previously have silently never matched a real request (this was true before this PR too, on the old bracket-index shape). Cookie keys are left as-is — Cloudflare doesn't case-normalize those.

exists/not_exists for both now use has_key(map, "key"), matching the idiom Cloudflare's own changelog documents for map-key existence checks (same as #263's query fix already used).

Scope notes

• ExpressionBuilder.fromVercelCondition/FieldMapper (the direct Vercel-native → Cloudflare path, not the unified-config path this PR fixes) has the identical bug, plus an unfixed keyed-query case of its own — but it's dead code, unreachable from any live command (confirmed via grep). Left alone with a code comment explaining why and what to fix first if it's ever wired back in.
• A keyed header/cookie condition no longer round-trips through WirefilterParser (it doesn't parse any(...)/has_key(...) syntax) — this is a deliberate, documented degradation matching the parser's own existing contract (unsupported construct → null, caller warns), not a silent misparse. Extending the parser to understand the new construct is real follow-up work, intentionally not bundled into this fix.

Test plan

• Regression tests for header (value comparison, exists, not_contains, negation, case-lowercasing) and cookie (value comparison, exists, not_in, case-preservation), each set mutation-verified
• Separately mutation-verified the case-normalization logic on its own (a distinct, easy-to-silently-break behavior from the core Array-vs-String fix)
• pnpm compile && pnpm test && pnpm lint all pass (1764 tests, 0 lint errors)

[gfargo]

Closing without merging — #278 landed first (merged as c529e57, ~seconds before this PR's CI finished) and independently arrived at the same fix via the same research (same any(field["key"][*] <op> value)/has_key(...) idiom, same buildKeyedMapExpression helper name), but went further than this PR did:

• Extended WirefilterParser to actually parse the new any(...)/has_key(...) syntax back into structured conditions — closing the round-trip gap this PR deliberately deferred to WirefilterParser doesn't round-trip keyed header/cookie/query conditions (any(...)/has_key(...) syntax) #277 (retroactively fixing it for Cloudflare ignores query condition's key; rateLimit.mitigationTimeout/countingExpression unvalidated #263's query case too, which had the same gap).
• Made header require a key (throws a clear error without one) — correctly closes a gap neither Cloudflare keyed header/cookie conditions likely emit wirefilter the API rejects (Array-vs-String, and indexing a String field) #269 nor this PR caught: an unkeyed header condition was compiling to http.request.headers eq "value", comparing a bare Map against a String, equally invalid.
• Noted http.request.cookies requires a Cloudflare Pro/Business/Enterprise plan.
• Verified end-to-end against the Cloudflare mock server (sync → diff reports zero phantom changes for keyed header/cookie/query conditions).
• Fixed a pre-existing broken test fixture in CloudflareRuleScenarios.test.ts that never actually exercised a valid header condition.

No action needed here beyond closing — see #278 for the real fix.