feat(safari): support Safari profiles (macOS Sonoma+) cookie stores

[mherod]

Problem

Safari (macOS Sonoma 14+) supports multiple profiles, each with isolated cookies. get-cookie explicitly ignores --profile for Safari and reads only the single default container path, so profile cookies are unreachable. Notably, yt-dlp does not support this either — implementing it would put get-cookie ahead of the reference.

Location:

• src/core/browsers/safari/SafariCookieQueryStrategy.ts:44-55 (single hardcoded path)
• src/core/browsers/safari/SafariCookieQueryStrategy.ts:500-503 (warns the profile is ignored)

Found in: yt-dlp cross-reference + WebSearch (codebase scan)
Type: enhancement (investigation required)

Context

// single path only
return join(home, "Library", "Containers", "com.apple.Safari", "Data", "Library", "Cookies", "Cookies.binarycookies");

// profile explicitly ignored at query time
this.logger.warn(`Safari does not support profile filtering. --profile "${this.profileName}" will be ignored; all Safari cookies will be returned.`);

Research Findings

• Safari cookies are known to live at ~/Library/Cookies/Cookies.binarycookies and ~/Library/Containers/com.apple.Safari/Data/Library/Cookies/Cookies.binarycookies.
• The per-profile storage layout (Sonoma+) is under-documented publicly; an investigation step is required (enumerate container subpaths; identify per-profile *.binarycookies).
• References:
  • CyberArk — The Current State of Browser Cookies
  • kawakatz/macCookies
• Complexity: Medium–Complex (discovery first).

Recommended Approach

1. Investigate the on-disk layout of Safari profile cookies on Sonoma/Sequoia (enumerate Safari container subdirectories; locate per-profile *.binarycookies).
2. Add Safari to --list-profiles enumeration once the layout is known.
3. Map --profile <name|uuid> to the corresponding binarycookies file; default to the current container path.
4. Replace the "not supported" warning with real filtering when a profile is supplied.
5. Tests/fixtures for ≥2 Safari profiles.

Acceptance Criteria

• Safari profile cookie store(s) located and documented in the issue/PR.
• --profile selects the matching profile's cookies for Safari.
• No-profile behavior unchanged (default container path).
• --list-profiles includes Safari profiles (if discoverable).
• Tests pass; no new lint errors.

[mherod]

Investigation: Safari profile cookie storage layout

Read-only inspection of the Safari container on a current macOS install (Safari with only the default profile present):

• Profiles live at ~/Library/Containers/com.apple.Safari/Data/Library/Safari/Profiles/<ProfileName>/ (observed: a single DefaultProfile/).
• The only *.binarycookies file in the entire container is the shared ~/Library/Containers/com.apple.Safari/Data/Library/Cookies/Cookies.binarycookies.
• Profiles/DefaultProfile/ contains no Cookies.binarycookies, and there is no per-profile Cookies/ directory.

Implication for implementation: per-profile cookies are not a simple Profiles/<name>/Cookies.binarycookies path swap. The default profile uses the shared top-level binarycookies store; non-default profiles most likely keep cookies in WebKit's per-profile WebsiteData / NetworkProcess storage (a different format and location), not the legacy binarycookies format. So #560 is a larger lift than path discovery — it likely needs a WebKit WebsiteData reader rather than an extension of the existing binarycookies decoder.

Caveat: this machine has only the DefaultProfile, so a true multi-profile layout couldn't be observed directly. The next discovery step (on a Sonoma/Sequoia machine with ≥2 Safari profiles) is to confirm where a second profile's cookies land — binarycookies vs WebKit WebsiteData — before committing to an implementation approach.