fix(asset): write decimals through the service that owns the cache

[TaprootFreak]

Closes #4578.

The defect

EvmDecimalsService.setDecimals() wrote through repoFactory.asset, the instance RepositoryFactory constructs itself. Every reader goes through AssetService, which holds a different instance of the same repository class. CachedRepository.invalidateCache() clears only the instance it is called on, so nothing told the readers' cache that decimals had just been filled — it kept serving the previous rows until the entry expired.

The impact was small: the job only fills rows that are still NULL, so it delayed a repair rather than serving a wrong value. The exposure belongs to the pattern, not to this field.

The fix

The write goes through AssetService, which owns the instance the cached reads are served from. AssetService.updatePrices did precisely that already and had exactly one caller, so instead of copying its body it is renamed to updateAssets and used by both jobs. Reading moves behind the service as well (getEvmAssetsWithoutDecimals), so RepositoryFactory.asset is left without a single caller.

updateAssets then took three corrections during review, each one closing a hole the previous version had left:

1. Invalidation in finally. The first version invalidated after the loop, so a failing update skipped it and left the rows written before it out of the cache — the very staleness this change removes.
2. Every update is attempted. Batching had silently given up the per-asset isolation the original loop had: one row that keeps failing would have blocked every asset queued behind it, on every run. Failures are collected instead of aborting.
3. The original errors survive. Collecting failures first reduced them to text, dropping type, stack and every cause after the first. It now throws an AggregateError carrying all of them and naming the affected ids.

On (3) a dedicated error class exposing failedIds was considered and rejected: neither caller inspects the error, both hand it to the cron, so it would be structure without a consumer.

The empty case is guarded inside the service rather than at the call site, so it holds for every caller. That also changes the five-minute price job, which previously passed an empty list and dropped the whole asset cache for nothing.

Tests

asset.service.update.spec.ts (new)

• every update written, cache invalidated once
• cache invalidated even when an update fails, so earlier writes are not left stale
• every update attempted when one in the middle fails, and the last one still reached
• the original errors are carried, asserted by identity rather than by message text
• nothing written and cache untouched for an empty list

evm-decimals.service.spec.ts (new)

• the write goes through the service that owns the cache
• several assets collected into a single write
• a failing token lookup does not take the other assets with it
• nothing collected when no asset is missing its decimals, and none when every lookup fails

Reverting the write turns three of the decimals tests red.

Not covered here

The pattern itself — a repository existing twice, in DI and in RepositoryFactory, with independent caches — stays as it is; nothing enforces the service boundary, so a future direct repository write could recreate this. Issue #4578 records the structural options.

Checks

npm run type-check, npm run lint and prettier --check clean; the new specs plus the asset.service and asset-prices-job suites green (13 tests).

[TaprootFreak]

Four review passes, three defects fixed. Each one was a hole left by the previous version of the same method, so they are worth naming:

1. The invalidation sat after the loop, so a failing update skipped it and left the rows written before it out of the cache — the exact staleness this PR removes.
2. Batching the writes had silently dropped the per-asset failure isolation the original loop had. One row that keeps failing would have blocked every asset queued behind it, on every run.
3. Collecting the failures reduced them to text, losing the type, the stack and every cause after the first.

The fourth pass found nothing.

One recommendation was deliberately not followed: a dedicated error type exposing failedIds. Neither caller inspects the error — both hand it to the cron — so it would have been structure without a consumer. AggregateError keeps the causes, which is the part that matters for whoever reads the log. Happy to be overruled on that.

CI green: build and checks, all three test shards, coverage, and the coverage ratchet.