IBKR connector: get_pa_allocation silently ignores the `date` parameter and returns the latest trading day

### What happened?

`get_pa_allocation` accepts a `date` parameter (historical snapshot, `yyyymmdd`). The parameter is
accepted without error, but the date requested has no effect on the response: every call returns the
latest available trading day, while `realtime:false` and a `date` field are echoed back with a date
that is *not* the one requested.

The tool description states:

> Historical snapshot date in yyyymmdd; omit for the live current-day view.
> Returns realtime:false with the date echoed.

The date is not echoed. There is no error — the call returns HTTP 200 with plausible, well-formed,
wrong data. For a financial tool this is the dangerous failure mode: a caller asking "what was my
sector allocation on 30 June" receives 15 July's allocation labelled as the answer, with nothing in
the response indicating the substitution.

### What did you expect to happen?

Either the requested date's allocation is returned with `date` echoing the requested value, or the
call fails with an explicit error (as it reportedly does for pre-inception dates).

### Steps to reproduce

Account base currency is EUR. **`currency` must be set to the account's base currency for this test
to be meaningful** — the documented behaviour is that any non-base currency "silently switches the
response to the prior trading day", which would confound the result. All three dates below are after
account inception (`start` = 20250716 from `get_pa_performance_all_periods`), so none should trigger
the documented pre-inception error.

1. `get_pa_allocation(type="ASSET_CLASS", currency="EUR", date="20260630")`
2. `get_pa_allocation(type="ASSET_CLASS", currency="EUR", date="20260714")`
3. `get_pa_allocation(type="ASSET_CLASS", currency="EUR", date="20251201")`
4. `get_pa_allocation(type="ASSET_CLASS", currency="EUR")` — no date, as control

Observed (run 2026-07-16):

| Call | `date` returned | `realtime` | Long-side weights returned |
|---|---|---|---|
| 1 — requested 20260630 | `20260715` | false | CO 0.03376609 / EQ 0.95396408 / CA 0.01226983 |
| 2 — requested 20260714 | `20260715` | false | CO 0.03376609 / EQ 0.95396408 / CA 0.01226983 |
| 3 — requested 20251201 | `20260715` | false | CO 0.03376609 / EQ 0.95396408 / CA 0.01226983 |
| 4 — control, no date | *(no `date` field)* | **true** | CO 0.03336266 / EQ 0.95455270 / CA 0.01208464 |

Calls 1–3 request dates spanning seven and a half months and return **identical payloads** — weights
match to 8 decimal places and the NAV totals are identical to 11 decimal places (absolute amounts
omitted here). A constant NAV across three different dates is by itself sufficient to show that no
date-specific data is being served.

Call 4 confirms the parameter is not inert: supplying `date` does flip the response out of realtime
mode (`realtime:true` → `false`). The date is parsed enough to switch modes, then discarded.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Interactive Brokers (IBKR) — first-party connector

### Error messages or logs

No error is surfaced. All calls return HTTP 200 with a well-formed payload. That is the substance of
the report: the failure is silent.

### Additional context

Surface: Claude Code (Claude Desktop, Code tab), where IBKR tools load and function normally. Other
IBKR tools tested in the same session behave correctly and agree with each other
(`get_account_summary`, `get_account_positions`, `get_account_trades`,
`get_pa_performance_all_periods`).

**What I could not verify:** I cannot inspect the JSON on the wire, so I cannot confirm whether
`date` leaves the client as a string. I believe it does — #557 reports the client coercing typed
params *to* strings (`string found, integer expected`), and `date` is declared `type: string`, so it
should validate and pass through. But that is an inference, not an observation. If the parameter is
in fact being mangled client-side, this may be a variant of #557 rather than a distinct server-side
fault. Someone able to see the request body can settle this quickly.

Reproduced on one account, one surface.

Possibly related, believed distinct:
- #557 — non-string params fail schema validation. Different failure mode: that one errors loudly;
this one returns 200 with wrong data.
- #571 — connector exposes zero tools on claude.ai web. Different surface; that one presupposes the
tools never load, this one presupposes they do.

Also worth flagging in passing: the `currency` description reads "default USD (account base
currency)". For this account the base currency is EUR, so the default is *not* the base currency, and
the documented non-base-currency behaviour silently applies to any caller who omits `currency`. That
compounds the issue above — a caller who omits both `currency` and reads the docs literally gets the
prior trading day for two independent reasons.