fix(mcp): the operator's spend cap can be narrowed, never widened

[enot3615]

const maxAmountUsd = typeof args.max_amount_usd === "number"
  ? args.max_amount_usd            // ← whatever the model asked for
  : ctx.config.maxAmountUsd;

A tool argument replaced the operator's limit outright. AIFINPAY_MAX_USD=0.10 and a model that asked for max_amount_usd: 1000 got 1000.

The cap is the one control an operator cannot express any other way in this server — and it was the one a prompt could remove.

Raised in the v1.3 audit follow-up as C-9, "fail-closed spend cap invariant", with exactly this remedy: Math.min(operator_cap, requested_cap).

Latent, not exploited

payable_fetch is not registered on the current server — it registers only agent_address, agent_passport_resolve, agent_quota. But this file is what SDK 2.0 re-registers, and a spend cap a caller can raise is not a cap.

The arithmetic

operator	requested	result
0.10	1000	0.10 — cannot widen
10	0.5	0.5 — narrowing is legitimate
unset	5	5 — no policy to violate
0.10	unset	0.10
unset	unset	no cap, the documented default

Math.min only where both exist. Refusing when the operator has set nothing would make the tool unusable for anyone who has not set the variable.

Also: NaN and Infinity are numbers

typeof x === "number" accepted both, and Math.min(0.1, NaN) is NaN — a cap that compares false against every amount. That is no cap, wearing the shape of one. Now requires Number.isFinite.

The schema description said "Defaults to AIFINPAY_MAX_USD env or no cap" — which described the bug. It now says the value can only lower the operator's cap.

Tests assert the shape too

The regression is a one-token edit back to ?. Arithmetic tests alone would not catch a rewrite, so Math.min(operatorMax, requestedMax) is asserted directly.

81 tests pass across 7 files. @aifinpay/mcp → 2.0.0-rc.4.

Refs AIFINP-211.