fix: correctly handle __Host and __Secure cookies when restoring state

[shadowusr]

What's done?

Some websites use __Host and __Secure cookies. We currently may work with them incorrectly. These cookies are special (per google):

• __Secure- cookies require an encrypted HTTPS connection and the Secure attribute to protect sensitive data from being intercepted or modified over insecure HTTP.

• __Host- cookies enforce maximum isolation by locking the cookie strictly to the issuing domain and the root path (Path=/), blocking subdomains from stealing or overwriting it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 69f70e201a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve the saved host for __Host cookies

When a state file or data object contains a __Host- cookie for a host other than the currently open page, deleting domain leaves the cookie with neither domain nor url. The DevTools path then lets Puppeteer fill the missing URL from the current page, and WebDriver defaults a missing domain to the current document, so the restore writes the host-only cookie to the wrong host instead of the saved one. This corrupts restored auth state for flows that restore saved cookies after navigating to a different origin; use the saved domain to build a URL or require navigating to that host instead of dropping it completely.

Useful? React with 👍 / 👎.