feat(scrape): declare headers in scrapeParamsSchema so custom headers reach the API

[kamalrana22]

Summary

Fixes #67.

Custom HTTP headers (Cookie, Authorization, User-Agent, ...) passed to firecrawl_scrape never reach the Firecrawl API, even though the API fully supports a headers option on /v2/scrape.

Root cause

The scrape handler already spreads all options through transformScrapeParams() into client.scrape() — but headers was never declared in scrapeParamsSchema, and zod object validation silently strips unknown keys. So the parameter is dropped during validation, before the handler ever sees it. (An earlier implementation passed unvalidated args through, which is why the workaround described in #67 used to work and no longer does.)

Changes

• Declare headers as an optional Record<string, string> in scrapeParamsSchema, with a description so MCP clients know when to use it.
• No handler changes needed: once the key survives validation, the existing spread already delivers it to the API. Because the same schema backs scrapeOptions in firecrawl_crawl and firecrawl_agent, the passthrough works there too.

Verification

Built and ran the server over stdio against a self-hosted Firecrawl instance, calling firecrawl_scrape with a Cookie header against https://httpbin.org/cookies (echoes received cookies):

• Before: {cookies: {}} — header silently dropped
• After: {cookies: {mcpfix: issue67}}, and tools/list now advertises headers in the firecrawl_scrape input schema

Use cases this unlocks: scraping pages behind cookie-based auth, regional consent walls (e.g. Google's EU consent page via its consent cookie), and sites that reject the default headless User-Agent.