Bug: Base Sepolia transactions refused for newly-created 7702 accounts, while wallet_getCapabilities reports the chain as supported

### Describe the bug

Newly-created Base Accounts cannot send any transaction on Base Sepolia (84532). The `keys.coinbase.com` popup shows "This chain is not supported. Base Sepolia is not supported. Please try a different chain." and rejects the request with `{ code: 4001 }`. Accounts created before the ERC-4337 to EIP-7702 provisioning change still transact on Base Sepolia normally, through the same popup, from the same app.

### Steps

**Reproduction**

1. Create a **new** Base Account (any surface: base.app, or the popup's own email signup).
2. Connect from a dapp whose wagmi config lists `baseSepolia`.
3. Sign in with `personal_sign`. This succeeds.
4. Send any transaction on 84532 (`eth_sendTransaction` or `wallet_sendCalls`).
5. The popup renders the unsupported-chain screen and rejects.

A 20-line standalone harness reproduces it with no bundler. Happy to attach.

**What works and what does not, for a new account on 84532**

| method | result |
|---|---|
| `eth_requestAccounts`, `wallet_connect`, `wallet_switchEthereumChain` | ok |
| `personal_sign` | ok |
| `eth_sendTransaction` | refused |
| `wallet_sendCalls` | refused |
| `eth_signTypedData_v4` | refused |

**Where the refusal comes from**

In the popup bundle (`keys.coinbase.com/static/main..js`), the unsupported-chain copy
(message ids `Zhuq4r` and `2leMnv`) lives only inside the wallet-upgrade component, alongside
`"We need to set up your wallet to transact on {chainName}. Scan the QR code with the Base app."`
and a `https://base.app/sync?targetChainId=…` link. Its predicate is:

```js
var j = dt.fromChainId(BigInt(c)), // c = target chainId
w = !(null != j && j.isTestnet || !f[c]); // f = supportedChainsToNetworkMap
if (!w) return /* "…is not supported. Please try a different chain." */
```

Base Sepolia is present in `f` (its `displayName` is what fills the error copy), so `isTestnet`
is the operative term. The screen is reached only via a hook that short-circuits when the account
has `factoryAddress`/`factoryCalldata` (ERC-4337) and otherwise checks
`isDelegatedEOA(address, chainId)` against the designator above.

So the refusal is not a chain-support decision. It is delegation provisioning refusing to run on
a testnet, surfaced with chain-support copy.

**Two things that look inconsistent**

1. For the very account it refuses, `wallet_getCapabilities` returns Base Sepolia as capable:

```json
"0x14a34": { "paymasterService": {"supported": true}, "atomicBatch": {"supported": true},
"atomic": {"status": "supported"}, "auxiliaryFunds": {"supported": true},
"dataSuffix": {"supported": true} }
```

EIP-5792 says a wallet that does not support a requested chain "MUST NOT respond with an
error, and MUST instead not include a key for the unsupported chain(s)." The wallet includes
the key, and the one EIP-5792-defined capability present, `atomic: { status: "supported" }`,
is spec-defined to mean the wallet will execute the calls atomically. It then refuses them.
A dapp doing capability-based feature detection has no way to know the chain is unusable.

2. CDP's EIP-7702 documentation states that testnet delegation on Base Sepolia is supported and
simply unsponsored: *"On testnets (Base Sepolia, Ethereum Sepolia), the delegation transaction
requires ETH in the user's EOA. Use the CDP Faucet to fund accounts for testing."* I understand
that page describes CDP Wallets rather than Base Account, so this is not a direct
contradiction. But it does suggest the obstacle is sponsorship, not chain support, and the
popup never checks the account's balance before refusing.

**Also worth noting**

- `preference: 'smartWalletOnly'` no longer produces a 4337 account. Reading
`@coinbase/wallet-sdk@4.3.6`, `preference.options` is only consulted at `util/provider.js:37`
to choose the injected extension, and `createSmartAccount.js` `getFactoryArgs()` carries
`// TODO: support creating factory data` and only echoes what the popup supplies. So there is
no client-side way to opt into an account type that works on testnets.
- SDK version is not a factor: `keys.coinbase.com/connect` serves byte-identical HTML for
`sdkVersion=2.4.0` and `2.5.7`, and the predicate reads neither `sdkName` nor `sdkVersion`.
- The bundle contains a feature flag named `scw_native_delegation` that selects between two
upgrade-screen variants, which may be related.

**Questions**

1. Is refusing all testnets in the delegation-provisioning flow intended, or a gap?
2. Is there a timeline for enabling 7702 delegation provisioning on Base Sepolia?
3. In the meantime, is there any supported path for a dapp to develop and test against Base
Sepolia with newly-created Base Accounts? If not, could `wallet_getCapabilities` omit chains
the wallet will refuse, so dapps can detect this and degrade gracefully instead of walking
users into a dead-end popup?

### Expected behavior

7702 delegation provisioning on Base Sepolia

### Version

- `@base-org/account` 2.4.0 and 2.5.7 (identical behavior) - `@wagmi/connectors` 6.2.0 (`baseAccount` connector), wagmi 2.19.5, viem 2.45.2 - Chains: `[baseSepolia, base]`; also reproduced with `@coinbase/wallet-sdk` 4.3.6 and `preference: 'smartWalletOnly'`

### Additional info

_No response_

### Desktop

iOS Chrome and Safari

### Smartphone

_No response_

Start with the @base-org/account and @coinbase/wallet-sdk integration points for eth_sendTransaction, wallet_sendCalls, and wallet_getCapabilities, then inspect the popup bundle's delegation-provisioning path and the scw_native_delegation variants. Reproduce the behavior on Base Sepolia with a newly-created account and compare the reported capabilities with the transaction outcome; done means the supported behavior and capability response are consistent.

Written by the indexing model from the issue text.