feat(scrypt): hard-cap LIMIT execution price (Phase 2 / followup to #3736)

[TaprootFreak]

Why

#3736 added a pre-trade reference-deviation check at 0.3 %. That check only fires at the moment we send NewOrderSingle. Two things can still get past it:

1. Market moves between check and fill. Scrypt acks the order ~ms later, by which point the quoted ask can already be above our cap.
2. The periodic edit loop in ScryptService.checkTrade re-prices resting orders to whatever Scrypt's current best ask/bid is — completely unaware of our 0.3 % rule. A resting order placed inside the cap can be edited back out of it on the next tick.

Reading the Scrypt AsyncAPI spec (#3737) confirmed there's no separate fee field to inspect — Scrypt embeds its commission in the quote (Fee: "0" on every Trade in the spec examples, AvgPx doc-string: "Does not include fees"). The only way to bound implicit cost is the LIMIT Price itself.

What

Make the cap hard by clamping every LIMIT price we send to reference × (1 ± maxPriceDeviation), for both placement and edits.

ScryptService

• sell(from, to, amount, priceCap?) — initial placement uses min(orderbookPrice, cap) for BUY, max(orderbookPrice, cap) for SELL.
• checkTrade(clOrdId, from, to, orderCreated?, priceCap?) — edit loop applies the same clamp before any OrderCancelReplaceRequest. Resting orders cannot be re-priced past the cap.
• applyPriceCap() — single static source of truth for the clamp; defensively returns the orderbook price for null/undefined/NaN/±Infinity/≤0 caps.

ScryptAdapter

• getAndCheckTradePrice returns { scryptPrice, priceCap, side }. Pre-trade check + cap computation share one pricingService.getPrice call.
• computePriceCap is the per-tick helper used by completion checks, recomputing the cap from a fresh reference so the protection adapts to market moves without needing extra DB columns.
• toPriceCap (static, public for testability) does the from-per-to → quote-per-base conversion. pricingService.getPrice(from, to).price is source/target (verified via Price.convert(amount) = amount/price in price.ts). That coincides with quote-per-base for side=BUY (from=quote, to=base) and requires inversion for side=SELL.
• All three placement paths (sell, buy, sellIfDeficit) and both completion checks (checkSellCompletion, checkBuyCompletion) wired through.

Tests

Added __tests__/scrypt.service.spec.ts and __tests__/scrypt.adapter.spec.ts (18 tests total) covering:

• applyPriceCap × {BUY, SELL} × {below cap, above cap, equal, undefined, null, 0, negative, NaN, ±Infinity}
• toPriceCap realistic BUY (ref 66'500 EUR/BTC → cap 66'699.5) and SELL (ref 1.5e-5 BTC/EUR → cap 66'466.67)
• A symmetry sanity test that locks the inversion direction in (BUY-cap / SELL-cap = (1+δ)/(1−δ))

Self-review bugs found and fixed in this PR

A self-review pass before requesting human review caught three correctness bugs in the original implementation (all in the second commit of this PR):

1. toPriceCap inverted on the wrong side. Initial code inverted for BUY (where the reference is already quote-per-base) and not for SELL (which actually needs inversion). The symmetry test now locks this in.
2. Notification was permanently suppressed. suppressRecurring: true combined with debounce causes Notification.isSuppressed to return true forever (the conditions are OR'd in notification.entity.ts:43-47). Dropped suppressRecurring so the 1h debounce works as documented.
3. applyPriceCap accepted invalid caps. Only priceCap == null short-circuited; 0/negative/NaN/±Infinity would have produced bogus LIMIT prices. Added Number.isFinite + positivity check.

Behavioural change

An order can now legitimately sit unfilled if the venue is priced beyond the cap for an extended period. That is the intended behaviour — better a stalled order than silent overpayment like 2026-05-21. After the existing 1 h-no-found timeout (ScryptService.checkTrade), the LM pipeline will fail and the alert fires.

Effect on the 2026-05-21 incident

Replay with cap = 0.3 %, reference ≈ 66'500 EUR/BTC → cap ≈ 66'700 EUR/BTC. The 13 fills at 66'479–66'484 would have filled normally (they were under the cap; our internal spread vs pricingService is what was high, not Scrypt's quote itself). The real win is in the bad case: if Scrypt's quote drifted up to 67'200 mid-fill, our LIMIT at 66'700 would simply stop filling instead of being edited up by checkTrade.

Out of scope (separate follow-up)

A spec-vs-code audit during this work surfaced unrelated drift between scrypt.dto.ts and the vendor spec (wrong ScryptTransactionStatus enum values, missing OrdStatus.Replaced, missing TransactTime on OrderCancelRequest/OrderCancelReplaceRequest, unhandled ExecType.CancelRejected/ReplaceRejected). These are not regressions introduced by this PR and are not addressed here. Tracked separately.

Test plan

• Unit tests added + passing (18/18 locally)
• lint, format, build green locally
• CI green
• DEV smoke test: force a Scrypt quote outside cap, confirm order is placed at cap price and does not fill until quote recovers
• DEV: trigger edit-loop with quote outside cap, confirm OrderCancelReplaceRequest is sent at cap price (or not at all if cap = current order price)
• Verify completion check still aggregates output correctly when order eventually fills

Supersedes

This PR contains all changes from #3736 (Phase 1: pre-trade deviation check + alert) plus the LIMIT-cap and the bug-fix commit. #3736 can be closed once this is merged.