Attribute anti-fraud and consent vendors, including by cookies and headers

[chrmod]

Adds the major bot-management vendors (Cloudflare, Akamai, DataDome, Imperva, PerimeterX/HUMAN, Kasada, AWS WAF) as anti-fraud, plus OneTrust/Cookiebot/IAB TCF consent cookies and AWS ELB.

Patterns can now also be matched by the cookies and response headers they set — attributing vendors a URL can't reveal (CNAME-cloaked / edge-integrated). New --- cookies / --- headers blocks (cookie names support a prefix* wildcard) and SDK matchCookie / matchHeader. See docs/response-signals.md.

[chrmod]

Follow-up: reaching the browser extension (design note)

Heads-up for reviewers on where this does and doesn't land today.

The Ghostery extension does not consume this package's SDK — it loads the serialized TrackerDB engine and attributes requests via @ghostery/adblocker's engine.getPatternMetadata(request) / engine.metadata.fromDomain() (no @ghostery/trackerdb dependency). So the matchCookie / matchHeader added here (which read trackerdb.json) are reachable by SDK / CLI / WhoTracks.me consumers but not by the extension. The signals also don't reach the engine binary today: FiltersEngine.fromTrackerDB only ingests pattern.filters, and extra pattern keys are dropped on serialize — so cookies / headers never make it into engine.metadata.

To light this up in the extension, the matching has to live in the adblocker engine's metadata, folded into the existing attribution path (not the blocking match(), since cookies/response-headers are only known post-response). Recommended design:

• Integrate into getPatternMetadata(request), not a public fromCookie/fromHeader. Add optional cookies / headers to the Request (fromRawDetails), and have getPatternMetadata fold cookie/header lookups into its existing unified IPatternLookupResult[] (same seenPatterns de-dup). One call returns URL + domain + cookie/header matches; the extension change is just attaching cookies/headers to the request it already builds.
• Data in Metadata, keyed by fastHash(name) — the same string→pattern index categories/organizations already use (not the implicit NetworkFilter domain path). Exact names in a CompactMap; the handful of * wildcard prefixes in a small serialized list scanned at query time. fromCookie/fromHeader remain internal resolvers behind getPatternMetadata, not public API.
• Carry cookies/headers on IPattern so merge() / fromTrackerDB keep working; extend fromTrackerDB to pass them through. This changes the metadata binary layout → ENGINE_VERSION bump.
• Not modeled as $header / $cookie filters: the adblocker has neither today, and building filter syntax + a match bucket for what is fundamentally a name→pattern hash lookup is far more surface than a direct reverse index (URL tokenization buys nothing for exact/prefix names).

Change surface: mostly @ghostery/adblocker (IPattern, Metadata, Request, getPatternMetadata, fromTrackerDB, version bump); the trackerdb data/JSON already carry the fields; the extension is a couple of lines. The SDK matchCookie/matchHeader in this PR can be dropped once that lands, or kept for non-engine consumers.

Interim (if attribution is wanted before the engine change): ship the cookie/header index in trackerdb's dist and have the extension match it in getMetadata — same data, no engine-format change, retired once the adblocker path ships.