Replay d-s and b cookies alongside d for browser-session (xoxc/xoxd) requests

[nitrocode]

Context

Follow-up from #141/#142 (the unexpected_user_agent force-logout fix) and #143 (browser-shaped headers). Looking at cookie handling specifically.

What's missing

Every browser-session (xoxc/xoxd) request in src/slack/client.ts, src/slack/files.ts, and src/slack/canvas.ts only ever sends the d cookie:

headers.Cookie = `d=${encodeURIComponent(auth.xoxd_cookie)}`;

A real logged-in browser tab sends d, d-s, and b together on every request. This isn't a request-time-only gap either: none of the four cookie-extraction paths capture d-s or b in the first place:

• src/auth/chrome.ts (AppleScript document.cookie read, only greps for d=)
• src/auth/brave.ts (SQLite query: where name = 'd')
• src/auth/desktop.ts (same SQLite pattern, where name = 'd')
• src/auth/firefox.ts
• src/auth/curl.ts (parse-curl, regex only matches d=(xoxd-...))

A previously reported issue (#13) has a reporter's own browser cookie table showing exactly this trio (b, d, d-s) present in a real session, for reference.

Why this matters

A session replaying only one of the three cookies a real browser always sends together is itself a fingerprint mismatch, independent of headers (#143) or User-Agent (#141/#142). We don't have confirmation Slack's enterprise anomaly detection checks for d-s/b presence specifically, but given how costly the failure mode is (force-logout of the real browser session, not just a failed request), it's worth closing this gap defensively.

Proposal

• Extend WorkspaceAuthSchema (src/auth/schema.ts) to optionally store d-s/b alongside xoxd_cookie.
• Update all four extraction paths + parse-curl to capture d-s and b when present.
• Update the three request sites (client.ts, files.ts, canvas.ts) to send all three cookies together when available, falling back to d-only for existing stored credentials that predate this change (so nobody's forced to re-auth).