fix(widget): carry landing message in the URL as well as window.name

[mike-doctorina]

Part of DoctorinaAI/doctorina#3940 (epic DoctorinaAI/doctorina#3911). Pairs with app-side PR DoctorinaAI/doctorina#3941.

Problem

The widget's primary path passed the typed message to the web app only via window.name. window.name lives in the originating browser tab, so when an iOS universal-link intercept tears that tab down (the app.doctorina.com deep-link bug fixed app-side in #3941), the payload is destroyed and the message is lost. The URL carried no copy on this path.

Change

• src/widget/tab-opener.ts: on the primary (window.open) path, also carry the message in the destination URL (buildTargetUrl(config, text)), so it survives a lost window.name. The web app already reads window.name first and falls back to the URL hash, so there's no double-handling — the hash is pure backup. The popup-blocked fallback is unchanged.
• Exported buildTargetUrl and normalizeMessage.
• Added tests/widget-tab-opener.test.ts — first unit tests for the widget's URL construction (default target, auto_accept_policies/referrer, default + overridable utm_medium, custom params, hash round-trip incl. unicode, custom target URL). 8 passed.

Notes

• This keeps the current plaintext transport (hardening only). The token-only handoff (#3911 §6, message stored server-side, only a token in the URL) is the long-term replacement and is tracked separately.
• No behavior change for the popup-blocked path or for embedders' data-* config.

npm run type-check, eslint, and vitest all pass.

[github-actions]

Visit the preview URL for this PR (updated for commit 75c0eb3):

https://doctorina-pages--pr-8-wcxf2c5t.web.app

_{(expires Thu, 25 Jun 2026 13:04:30 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 9cce88f2a7a5916aaad58a2b37340f46f15c32e8}