[BUG] py_clob_client (v1) cannot trade on new Polymarket Magic Wallet accounts (sigtype=3 not supported)

[vicjayjay]

Summary

py_clob_client (v1) does not support signatureType=3 (POLY_1271) at all — its
SignatureType enum only defines EOA=0, POLY_PROXY=1, and POLY_GNOSIS_SAFE=2. However,
all new Polymarket accounts created via "Connect Wallet" or "Email Login" since the
Pectra/EIP-7702 rollout default to signatureType=3 (Magic Wallet / Privy embedded wallet).

Result: any developer onboarding a new Polymarket user with this SDK hits an immediate dead end.
There is no documented workaround.

(Sister issue with deeper TSS root-cause analysis filed at
Polymarket/py-clob-client-v2#57)

Environment

• py_clob_client 0.34.6
• Python 3.11
• Polygon mainnet (chainId=137)
• Magic Wallet account created via Polymarket UI (email login, Privy embedded wallet)
• Private key extracted via Polymarket UI's "Export Private Key" feature

Reproducer

from py_clob_client.client import ClobClient
# (1) Cannot construct client with sigtype=3 — not in py_order_utils.model.signatures
c = ClobClient(host="https://clob.polymarket.com", chain_id=137, key=PK,
               signature_type=3, funder=MAGIC_WALLET_ADDRESS)

# (2) ClobClient init may not error, but order build does:
from py_clob_client.clob_types import OrderArgs, OrderType
args = OrderArgs(token_id=..., price=0.50, size=5.0, side='BUY')
signed = c.create_order(args)
# => ValidationException("Invalid order inputs") from py_order_utils/builders/order_builder.py:89
#    The check: data.signatureType not in [EOA, POLY_GNOSIS_SAFE, POLY_PROXY]
#    Sigtype=3 is excluded from this whitelist.

# (3) Even if you bypass validation by setting sigtype=2 (POLY_GNOSIS_SAFE) and signing
#     anyway, Polymarket's CLOB API rejects:
# => 400 {"error":"the order signer address has to be the address of the API KEY"}

Root cause (verified empirically — see v2 issue for full TSS analysis)

The Magic Wallets that all new Polymarket users get are EIP-7702 / Privy embedded wallets that
require Privy's threshold-signature service to produce valid signatures. The "private key"
exposed via the Polymarket UI's "Export Private Key" feature is only the user's share of the
Privy TSS — the actual signing requires combining with a server-held share.

ECDSA recovery on a captured working UI signature returns a Privy-controlled identity
(0xaac44c2EB50D1ad03edAa3A727F4F5AE8000ad9f), NOT the user's exported PK address. Therefore no
client-side signing can produce valid orders for these accounts using just the user's PK.

Requested fix (any of these)

1. Add POLY_1271 = 3 to the SignatureType enum + multi-part signature builder support
   (matching the format used by Polymarket UI), AND integrate with Privy's signing service via
   their public SDK, OR
2. Provide a documented workaround — e.g., guide users to sigtype=0/2 wallets or expose an
   alternative account-creation path that doesn't use Privy embedded wallets, OR
3. Document the limitation explicitly in the README so developers don't waste time
   independently rediscovering it.

Impact

• All new Polymarket users (post-Pectra rollout) cannot use this SDK to trade
• Older users with sigtype=0/1/2 accounts are unaffected
• Third-party trading bots and tools cannot onboard new users at all
• The SDK appears functional (init + balance queries succeed) — failures only manifest at order
  placement, wasting developer time on debugging