Add Zen Browser support

[jeremy-albinet]

What

Adds Zen Browser (a Firefox fork) to the list of browsers gh image can read the user_session cookie from.

Why

Hit no session token found because Zen's cookies aren't in any of the currently-searched stores — Zen keeps its own profile tree (~/Library/Application Support/zen/Profiles/… on macOS, ~/.zen / Flatpak / newer XDG paths on Linux, %AppData%\zen on Windows), separate from Firefox's. The README's session-token override section already documents a manual sqlite3-based workaround for unsupported Firefox forks (Floorp, LibreWolf); this closes that gap for Zen with native, automatic detection instead.

Approach

Rather than reimplementing Firefox-fork cookie parsing inside this repo, I upstreamed proper Zen support into kooky itself, matching how every other browser here is wired (a blank-imported kooky.CookieStoreFinder):

• Add Zen Browser support browserutils/kooky#118 (open, not yet merged): adds browser/zen, mirroring browser/firefox's architecture exactly — same profiles.ini format, same cookies.sqlite/sessionstore.jsonlz4 schema, just a different profile-root search. Verified end-to-end against a real Zen install; cross-compiles clean for darwin/linux/windows (amd64+arm64) and android/arm64.
• This PR: blank-imports kooky/browser/zen in internal/cookies/cookies.go (identical one-line pattern to the other seven browsers), updates the "no session found" message, and updates docs.

Since kooky#118 isn't merged/released yet, go.mod carries a replace directive pinning to that PR branch as a resolved pseudo-version (reproducible, doesn't depend on the branch continuing to exist). This should be removed once kooky#118 merges and ships in a release — swap to the real require version and run go mod tidy. Flagged with a TODO in documentation/architecture.md's Dependencies section. Happy to hold this PR until kooky#118 merges instead, if you'd rather not carry a temporary replace — whichever you prefer.

Testing

• go build/vet/test ./... all pass.
• Verified end-to-end via cookies.GetGitHubSession(nil) against a real Zen install: correctly finds and returns the user_session cookie from the Zen profile's cookies.sqlite.
• gofmt -l . clean.

[drogers0]

Thanks @jeremy-albinet.

Kooky is in an awkward spot right now (#44): merging this means shipping a release that replaces onto an unreleased fork branch, and across all the browsers I'd increasingly end up maintaining my own kooky fork to stay current, which is exactly what I'm trying to get away from.

v1.3.0 added an alternate, more actively-maintained cookie backend, HackBrowserData, selectable at build time (-tags hbd). From what I can tell it doesn't support Zen either, but it's under active development and would likely be more receptive to a Zen PR than kooky has been to its backlog. If you're up for it, upstreaming Zen there is probably the more durable path, and it'd land on that build without any replace.

In the meantime, Zen users on v1.3.0 have a workaround that avoids browser cookies entirely: if you have a gh token, gh-image now tries a token-based upload first (#49). Setting GH_SESSION_TOKEN to Zen's user_session value works too.

I'll leave this open for tracking, but to be upfront, I wouldn't expect movement on it as it stands in the near term.

[jeremy-albinet]

Hey @drogers0
Totally makes sense, I let you decide to lock it and/or close it without issue.

I'll start using gh token on my side to test it also