1581 add upper cap limits to chosen websocket endpoints to increase resilliency

[cranycrane]

Summary

Adds upper-cap / bound-checking limits to several server endpoints to improve resilience against unbounded memory growth and abusive request patterns (closes #1581). Each cap is covered by unit tests.

Changes

WebSocket — cap in-flight getMempoolFilters responses
Per-connection semaphore (maxWebsocketMempoolFiltersResponses = 4) bounds each request from acceptance until its response is written (or drained on close), capping the peak memory held in large filter responses; excess requests are rejected with a mempool_filters_limit error. Adds a release/finalize hook on WsRes so the slot is freed exactly once across write, drain-on-close, and overflow paths.

Fiat rates — bound and normalize currency selectors
Replaces removeEmpty with normalizeFiatCurrencies (trim, lowercase, dedupe, bound) applied once at the entry points (GetCurrentFiatRates, GetFiatRatesForTimestamps, GetBalanceHistory, GetXpubBalanceHistory) before any per-result maps are allocated; downstream helpers rely on the pre-normalized slice. New limits MaxFiatRatesCurrencies = 128 (applied to the raw selector list length) and MaxFiatRatesCurrencyCodeLength = 16 return a client-facing error when exceeded.

EVM — harden ERC-1155 TransferBatch log parsing
Rewrites offset/length handling with explicit bounds and overflow checks to avoid possible OOM / out-of-range slicing from malformed log data, validating total data length before allocating the result slice.

Behavior changes

• A currency selector longer than 16 characters is now rejected with a public APIError (HTTP 400 on REST). The REST tickers endpoint never splits ?currency= on commas — it passes the whole value as a single selector — so a comma-joined value is only rejected once it exceeds 16 chars. ?currency=usd,eur,gbp,jpy (15 chars) therefore still returns 200 with {"usd,eur,gbp,jpy": -1} exactly as before; only a longer value such as ?currency=usd,eur,gbp,cad,jpy (19 chars) now returns 400 "currency code too long, max 16".
• The currency-count cap (128) applies to the raw selector list length before deduplication, so the validation work itself is bounded by the cap; a longer list is rejected even if it would deduplicate to fewer entries. This cap only bites on the array-accepting WS methods (getCurrentFiatRates, getFiatRatesForTimestamps) and the balance-history paths; the single-param REST tickers endpoint always passes 0 or 1 selector, so it can never trip the count cap.
• More than 4 getMempoolFilters requests in flight on one websocket connection (accepted but not yet written back) are rejected with a mempool_filters_limit error.

Tests

• server/websocket_test.go — mempool filters slot capping, including release after a successful write (via outputLoop over a live connection) and drain-on-close
• api/fiat_rates_api_test.go, api/fiat_balance_history_test.go — currency normalization/limits
• bchain/coins/eth/contract_test.go — malformed ERC-1155 batch logs

[pragmaxim]

Automated review of the cap-limit changes. The core logic is sound — the ERC-1155 TransferBatch bounds/overflow hardening in particular holds up well (candidate concerns about countIds misuse and erc1155BatchOffsetHex rejecting valid <0x40 offsets were checked and refuted). Findings below are behavior-change + cleanup, no crashes.

Inline comments cover the actionable items. One extra very-minor nit not inline (the function isn't in the diff): getFiatRatesResult (api/fiat_rates_api.go:81 and :104) still calls strings.ToLower on each selector, but the slice it receives is already lowercased by normalizeFiatCurrencies — redundant, bounded work. (Note line 72 is not redundant; it iterates raw ticker-map keys.)

[pragmaxim]

Two nit-level comments below. The rest of the review found no correctness or security issues — the websocket slot lifecycle and the ERC-1155 bounds math both hold up, all tests pass with -tags unittest, and go vet is clean.