IBKR connector: get_option_data fails universally with generic error; same query succeeds via IBKR REST API directly

### What happened?

The IBKR connector's `get_option_data` tool has failed on **every call since 2026-07-28 13:57 ET** (~46+ hours, still failing as of 2026-07-30 12:48 ET). Every invocation returns the same generic error regardless of parameters.

The fault is isolated to this one tool:
- `get_option_parameters` (same chain service) **succeeds** and returns a correctly rotated expiration ladder every day
- All other IBKR tools (~20+: account, positions, orders, snapshots, watchlists) work normally
- The **identical query succeeds against IBKR's Client Portal REST API directly** (same account, same day), so this is not an IBKR backend outage, entitlement, or auth problem

Isolation matrix - all combinations fail:

| Variable | Values tested |
|---|---|
| Underlyings | SPY (756733), QQQ (320227571), AAPL (265598), IWM (9579970), IBKR (43645865) |
| Routing | SMART and IBUSOPT |
| Expiration class | weekly (`regular:false`) and monthly (`regular:true`) |
| Strike ranges | narrow (4 pt), wide (22 pt), omitted entirely |
| Chain size | small (~12 expiries) and large (35+) - rules out timeout/scale |
| Time | repeatedly across 2026-07-28, 07-29, 07-30 |

Direct REST proof (local authenticated Client Portal Gateway, same account):
1. `GET /v1/api/iserver/secdef/search?symbol=IWM&secType=OPT` => 200 OK
2. `GET /v1/api/iserver/secdef/strikes?conid=9579970§ype=OPT&month=AUG26` => 200 OK, full call/put strike arrays
3. `GET /v1/api/iserver/secdef/info?conid=9579970§ype=OPT&month=AUG26&strike=291&right=C` => 200 OK, contracts with conids (e.g. 897988329 = IWM AUG 14 '26 291 C)

Conids minted this way work perfectly through the connector afterwards (`get_price_snapshot` returns live bid/ask/OI/IV; watchlist tools accept them).

Impact: option contract discovery through the connector is completely blocked - `search_contracts` cannot resolve options, and `create_watchlist`/`edit_watchlist` require conids that only `get_option_data` can mint.

### What did you expect to happen?

`get_option_data` should return the per-strike option chain rows (bid/ask, strikes, contract identifiers) for a valid `expiration_id` obtained from `get_option_parameters` - consistent with how the underlying IBKR REST endpoints (`/iserver/secdef/strikes` + `/iserver/secdef/info`) respond immediately with full data for the same account, same underlying, and same expiration.

### Steps to reproduce

1. Connect the first-party IBKR connector on Claude.ai (OAuth completes; all tools surface normally).
2. Call `get_option_parameters` with `underlying_contract_id: 9579970` (IWM) => succeeds, returns the expiration ladder.
3. Call `get_option_data` with any id from that ladder, e.g. `expiration_id: "9579970@SMART/OPT/SMART/20260814/IWM/0"`, `min_strike: 285`, `max_strike: 296`.
4. Observe failure: `Error invoking method: An error occurred. Please try again later.`
5. Repeat with any underlying, route, expiration class, or strike range - identical failure every time.
6. Run the equivalent query via IBKR's Client Portal Gateway REST API (`/iserver/secdef/search` => `/strikes` => `/info`) - succeeds immediately, returning the data the connector cannot.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Interactive Brokers (IBKR) - first-party/pre-built connector (https://api.ibkr.com/v1/api/mcp)

### Error messages or logs

```shell
Error invoking method: An error occurred. Please try again later.

(Identical text on every get_option_data call since 2026-07-28 13:57 ET, across all underlyings, routes, expirations, and strike-range shapes. No further detail surfaced.)
```

### Additional context

Possible root cause: IBKR's documented sequence is `search => strikes => info`, and `/iserver/secdef/info` reads a server-side cache that `/strikes` populates - calling `/info` cold returns `{"error":"No Contracts retrieved "}`. If the connector's `get_option_data` calls these out of order, skips the priming step, or mishandles the strikes response, it would produce exactly this universal failure while everything else stays healthy.

Market data entitlements confirmed active (US equities Networks A/B/C + OPRA, Non-Professional); live per-contract option quotes return fine via `get_price_snapshot` once a conid exists.

Related but NOT duplicates: #405 (OAuth expiry) and #571 (connected but zero tools) are auth/registration issues - this connector is fully authenticated with all tools visible; only this single tool fails.

Workaround in use: mint conids via the REST gateway manually and seed them into a watchlist; `get_watchlist` then supplies identifiers to the rest of the toolset.