feat: send cookies with every request during a clone

[didimitrie]

What

Adds a --cookie flag to kage clone so a site behind a login or a region/cookie wall can be mirrored. The cookies ride on every request a clone makes, not just the page render:

• Chrome page navigations — seeded into the browser before the first load
• Asset downloads — Cookie header on the HTTP fetch
• robots.txt fetch
• sitemap.xml fetch

This keeps the authenticated session consistent across the whole run rather than only the rendered pages.

Usage

# single cookie
kage clone --cookie "session=abc" example.com

# repeat the flag
kage clone --cookie "session=abc" --cookie "theme=dark" example.com

# paste a whole Cookie header straight from devtools
kage clone --cookie "session=abc; theme=dark" example.com

Notes

• Browser cookies are scoped to the seed host and its subdomains; the HTTP fetches send the same header.
• Because off-domain assets are left on the live web by default, the cookies are not leaked to third-party hosts (a nice security property that falls out of the existing asset policy).
• --cookie accepts a single name=value, repeats, or a full header in one value; malformed input is a clear usage error.

Tests

Added coverage for:

• Config.CookieHeader serialisation (incl. empty-name skipping)
• the asset downloader sending / omitting the Cookie header
• fetchSitemap sending the cookie
• the Chrome cookie-param building
• CLI parseCookies, including malformed-input errors (the cli package had no tests before)

go build ./..., go vet ./..., gofmt, and the full go test ./... all pass.

README, CLI reference (docs/content/reference/cli.md), and CHANGELOG (Unreleased) updated.

🤖 Generated with Claude Code

Closes #9

[zhaobokai341]

No one process?

[SihanTeng]

The current HTTP path can send the supplied session cookie outside the seed origin.

asset.Downloader.try adds the raw Cookie header to every URL it receives. The default asset policy reduces the exposure, but --all-asset-hosts deliberately downloads third-party assets, so using that flag with --cookie sends the seed credentials to those hosts. Same-registrable-domain asset hosts also receive the header even though the cookie was supplied for the seed host.

Sitemaps are a second path: robots.txt may advertise a cross-origin sitemap, and a sitemap index may point to children on another host. collectSitemaps follows those URLs and fetchSitemap attaches the same cookie without checking their origin.

I think the HTTP cookie needs to be selected per request URL, with the safest default being the exact seed host. Requests to other hosts should omit it unless the user explicitly supplied cookie domain semantics. Tests should cover --all-asset-hosts, an external robots sitemap, and an external child sitemap. The Chrome cookie jar can remain scoped independently.