fix(alerts): evaluateAll() no longer redundantly re-fetches every alert per asset

[davidishere1]

Summary

alertsService.evaluateAll() already fetches and parses every alert once via list() purely to compute the distinct set of watched assets — then called evaluateForAsset(asset, price) once per distinct asset, which independently re-fetched the full ID list and re-fetched/re-parsed every single alert from Redis again, discarding everything that didn't match. For A distinct assets and M total alerts, one cycle performed on the order of A × M sequential Redis round-trips instead of O(M).

evaluateAll() now groups the alerts it already has from list() into a Map<asset, Alert[]> in memory and evaluates each group directly, so a full cycle costs exactly one alerts fetch plus one price lookup per distinct asset — never more Redis round-trips than there are alerts + assets.

evaluateForAsset() itself is unchanged in behavior (still does a fresh Redis read when called directly — see the code comment on why that's intentional), just with its own id→alert fetch batched via Promise.all instead of a sequential loop.

1. refactor: extract the trigger/cooldown/fire/persist logic into evaluateAlertList(alerts, priceUsd), operating on an already-fetched array
2. perf: batch evaluateForAsset's own id→alert fetch via Promise.all
3. fix: the actual fix — evaluateAll() groups its single list() fetch by asset in memory instead of calling evaluateForAsset per asset
4. test: regression test asserting evaluateAll()'s Redis call count doesn't scale with distinct asset count (verified it fails against the pre-fix code: 4 zrevrange calls instead of 1)
5. docs: explicit code comment on why evaluateAll() takes one snapshot rather than re-reading per asset (no correctness reason — an alert created mid-cycle is picked up next cycle either way)
6. test: multi-asset isolation + remove/persist correctness through the new grouped evaluateAll() code path
7. docs: note a secondary-index follow-up direction (per the issue's "additional edge cases") as a documented out-of-scope improvement, not implemented here

Acceptance criteria

• evaluateAll() performs exactly one full alerts fetch (list()) per cycle, not one per distinct asset
• Redis round-trips scale with matching (alert, asset) pairs, not distinct_assets × total_alerts
• New test with multiple distinct assets + mocked Redis asserts cache.get/zrevrange calls don't grow multiplicatively with asset count
• Existing test/alerts.test.js behavior (which alerts fire, cooldown, non-repeat removal) is unchanged — all 22 original tests pass unmodified

Test plan

• npx jest test/alerts.test.js — 25/25 passing (22 original + 3 new)
• Full suite: npx jest — 373/373 passing across all 39 suites, run against a local Redis matching CI's service container
• npx @redocly/cli lint openapi.yaml — passes (untouched by this change)
• Manually verified the new regression test fails against the pre-fix evaluateAll (4 zrevrange calls for 3 assets) and passes against the fix (1 call)

Closes #132

[prodbycorne]

ci passed