fix: forward cookies on local-discovery path (dropped for auth-walled URLs)

[shrinishLT]

Summary

processSnapshot.ts has two parallel functions emitting the processedSnapshot payload:

Function	Used when	Includes cookies field
prepareSnapshot (line 44)	Remote discovery (USE_REMOTE_DISCOVERY / config.useRemoteDiscovery)	✅ yes (line 281)
processSnapshot (default export, line 288)	Local discovery — the default path	❌ no

This PR adds the missing cookies field to the local-discovery return so the two paths emit the same payload shape.

Why this matters

The CLI's discovery flow navigates a separate Playwright instance to snapshot.url to fetch and cache page resources. For customers whose URL is behind authentication (Veeva Vault, internal apps with SSO), the discovery browser needs the session cookies captured by the SDK to authenticate.

With local discovery, those cookies are silently dropped from the payload. The discovery Playwright opens the URL unauthenticated, fails to fetch:

• Auth-walled page assets (e.g., Vault's /ui/annotate/makepageimage?n=N PDF page images)
• Customer's tenant CDN (e.g., static-assets.veevavault.com CSS/JS bundles)

…and the snapshot uploaded to dotui has zero useful CSS/JS/images. The rendered screenshot is blank or grossly mis-styled.

Reproduction with real customer DOMs

Two captured Veeva Vault payloads from the same customer's test suite:

	Old payload	New payload
Top-level keys	[..., 'cookies', ...]	['name','url','dom','resources','options']
cookies field length	384 chars (IS_SELENIUM=true; veevaUserSsoSettings=…; VAULT_DATE_FORMAT_TYPE=…)	0 (field absent)
Cached makepageimage PNGs in resources	11 (pages 20–30)	0
Rendered snapshot	Pages visible	Blank / empty buffer

Same customer, same test pattern — the only thing that changed in the payload shape was the disappearance of cookies. Traced back to this dual-function divergence.

The fix

     return {
         processedSnapshot: {
             name: snapshot.name,
             url: snapshot.url,
             dom: Buffer.from(snapshot.dom.html).toString('base64'),
             resources: cache,
-            options: processedOptions
+            options: processedOptions,
+            cookies: Buffer.from(snapshot.dom.cookies ?? '').toString('base64'),
         },
         warnings: [...optionWarnings, ...snapshot.dom.warnings],
         discoveryErrors: discoveryErrors
     }

Identical pattern to the existing prepareSnapshot return at line 281 — just brings the local-discovery path to parity.

Scope / risk

• One file, one line added (plus the trailing comma).
• Forward-compatible: dotui already handles the cookies field on the payload (the remote-discovery path has been emitting it). For customers whose snapshot.dom.cookies was empty/undefined before, Buffer.from('').toString('base64') = '', so they get an empty cookies field — same effective behavior as before.
• No new options, no new behavior for non-auth-walled snapshots.

Test plan

• Builds locally (pnpm run build).
• Reviewer: install this build for a customer test that hits an auth-walled URL (Veeva Vault, internal SSO app). Confirm the next snapshot payload now contains a non-empty cookies field and the page renders with proper styling in dotui.
• Regression check: a public-URL snapshot (Wikipedia, etc.) where cookies are empty — should be unchanged.

Note on the dual-function divergence

This is the third bug caused by prepareSnapshot and processSnapshot diverging in this file. The first two (custom-scroll flag forwarding + the user-facing warning) were addressed in PR #522. Worth a follow-up refactor to share the payload-construction code between the two paths, but kept out of this PR for tightness.

🤖 Generated with Claude Code