feat(widget): bind chainId into bridge sign-in (multi-signer) — D-027-v3 §4

[gitchadd]

What

Binds chainId into the support bridge sign-in, the widget half of the D-027-v3 multi-signer (EOA + ERC-1271 + ERC-6492) upgrade.

The bridge is changing its sign-in message format to bind chainId:

${purpose}:${address.toLowerCase()}:${chainId}:${timestamp}

where purpose is support.p2p.me:sign-in, and the POST /auth/sign-in body gains a chainId field. ERC-1271 verification is chain-bound (it reads isValidSignature on the wallet contract at a specific chain), so the chainId must be bound into the signed string, not sent as a sidecar, or a Base Sepolia signature replays against the Base verifier. The widget signs and posts that payload, so it MUST match the bridge byte-for-byte or every sign-in 401s.

Source of truth: support/SYMMETRIC_CHATWOOT_DESIGN.md §4.3–4.4.

Changes

• SupportSigner gains optional chainId (the wallet's chain).
• signInWithBridge binds chainId into both the signed message and the POST body, sourced from signer.chainId, defaulting to 84532 (Base Sepolia) to match the widget's existing chain default across contracts.ts / useOrderStates / the order machines. New exported buildSignMessage helper mirrors the bridge's, with the address lowercased.
• Privy and Thirdweb adapters carry chainId through to the SupportSigner.
• Tests: new message-format assertion (...:8453:<ts>), body.chainId assertion, message-vs-body consistency check, default-to-84532 case, and adapter passthrough. README sign-in step updated to the new format.

All customer sign-in callers (Support, ContactSupport, PaymentHistoryWithSupport) route through the single signInWithBridge chokepoint, so binding chainId there covers every path. (The ops sign-in path / opsSessionCache.ts is not on main yet — it lives on feat/support-ops-mode — so it is out of scope here and will pick up the same change when that branch lands.)

⚠️ BREAKING — lockstep release

This is a breaking, lockstep change with the companion bridge multi-signer PR. The widget and bridge must merge and deploy together or every sign-in fails on a message mismatch (the bridge recomputes a different message and returns 401). Rollback = revert both.

The bridge side also moves an eth_call onto the sign-in hot path (1271/6492 verification), which intersects the open support bridge rpc fix item (move off public RPC onto Alchemy).

Verification

npm run verify green:

• tsc --noEmit (typecheck) clean
• tsc --noEmit --project tsconfig.examples.json (examples typecheck) clean
• node:test 86 pass / 0 fail
• vitest 60 pass / 0 fail
• tsup build (ESM + CJS + DTS) success

[gitchadd]

Pushed bf8d94e addressing the adversarial review (hard cutover, lockstep with bridge #20):

• chainId is now resolved from the live connector at sign time (Privy CAIP-2 eip155:<n> parsed in-adapter; Thirdweb active chain.id), not a cached prop.
• Removed the 84532 default; chainId is mandatory on the support path and throws a clear error if unresolvable — no silent wrong-chain signing.
• Golden-vector test asserts the produced message is byte-identical to the bridge contract; added symmetric Thirdweb adapter coverage.

build + 86 node + 69 vitest green. Merge/deploy together with bridge #20.

[gitchadd]

Pushed 659e27c (fresh re-review fixes):

• (MED, doc) README 'What happens on click' rewritten to the shipped hard cutover — chainId resolved live via signer.getChainId(), mandatory, throws before signing if unresolvable, no 84532 default.
• (LOW) chainId guards tightened to Number.isInteger (rejects e.g. eip155:8453.5); Privy CAIP-2 parser now rejects empty/0/non-positive instead of silently yielding 0.

build + 71 tests green. Lockstep with bridge #20.