Link wallet to current session

Bind the caller's executor profile to their current Supabase session so worker-auth endpoints (apply, submit, withdraw) can resolve it.

This is the bootstrap step that replaces the revoked link_wallet_to_session RPC (migration 092) and the anon-revoked get_or_create_executor (migration 111). The wallet MUST sign:

Execution Market: link wallet <wallet> to Supabase user <sub> at <ISO8601 UTC>

The <sub> is the caller's JWT subject — binding it into the signed message stops a captured signature from being replayed under a different JWT to hijack the executor. The signature proves ownership of the wallet, which authorizes binding executors.user_id to the JWT sub (the 'proven owner' rule from migration 111). Timestamp must be within the last 10 minutes. This endpoint does NOT use worker-auth (that's circular — the link is what makes worker-auth resolvable); it validates the raw Supabase JWT plus the wallet signature directly.

Smart-wallet signatures (ERC-1271 / ERC-6492): signatures that are not 65 bytes are verified on-chain via isValidSignature against the wallet contract on the platform's default network. ERC-6492 envelopes are unwrapped for DEPLOYED wallets; undeployed (counterfactual) 6492 wallets are rejected with a distinct error (erc6492_wallet_undeployed) until the wallet is deployed.

Alternative proof (Dynamic embedded wallets only): pass dynamic_jwt (the Dynamic session JWT) instead of message+signature. The server verifies it against Dynamic's JWKS (RS256, exp, scope includes user:basic, environment_id match) and requires the wallet in verified_credentials[] with wallet_provider == 'embeddedWallet'. External wallets must keep using the signature flow.

Alternative proof (web sign-in through Execution Market's authorization server, e.g. Continue with PayBox): pass oauth_access_token with oauth_code_verifier and nothing else — an access token issued by https://auth.execution.market to the web app's own client (https://execution.market/oauth/client-metadata.json) after PayBox signed the consent message for the browser that started the sign-in, and the PKCE verifier of that sign-in. Accepted for the wallet its sub names, within 10 minutes of issue, once, and only with the verifier behind the PKCE challenge the token carries. That client never gets a one-click consent, a refresh token or a code for a pasted or delivered signature, so each of its tokens follows a wallet signature made for that browser. A token issued to any other client (claude.ai, ChatGPT) is refused.