[LWDM] chore(aggregated-assets): move domain layer behind shims (LIVE-35226) - #20345

Addresses review on #20345.

domain/entity/README.md requires each entity package to define its canonical
model as a Zod schema: 'Use zod for schema definition', with schema.ts and
schema.test.ts listed as required. Both new entity packages shipped plain
TypeScript interfaces instead, which diverged from that convention.

Converted to the market-sentiment layout: schema.ts holds the Zod schema,
types.ts infers the type, schema.test.ts covers validation, barrel re-exports
both.

Behaviour-neutral. The schemas use plain z.object without .brand(), so z.infer
produces types structurally identical to the previous interfaces - live-common
still typechecks with zero errors and the characterization tests pass unchanged.
Nothing calls .parse() at the api boundary yet; that is LIVE-35232.

Two deliberate loosenesses are documented and tested rather than tightened:
InterestRate.type stays a plain string because DADA sends kinds outside ApyType
and consumers drop them, and fetchAt stays a plain string rather than
DateTimeIsoSchema because nothing reads it, so validating the format could only
discard otherwise-good rates.

Also fixes the Domain Test CI failure: the job installs only ./domain/** and
./shared/**, so @shared/env's transitive @ledgerhq/live-env was unresolvable.
api.test.ts now mocks @shared/env with a factory so the real module is never
required.

And trims pnpm-lock.yaml to the three new importers only. The peer-range
rewrites pnpm emitted for any-observable and @storybook/addon-react-native-web
were cosmetic - reverting them keeps 'pnpm install --frozen-lockfile' passing,
so the diff is now purely additive.

Addresses @ysitbon's review on #20345: comments 4, 5, 6, 7, 8 and 9.

shared/api-services already exists on develop and its README explicitly names
this migration: 'api-aggregated-assets is a placeholder for DADA ... when it
migrates, its base belongs here as src/services/dada/ rather than as another
standalone createApi'. I had missed it because I checked before rebasing.

Adds services/dada with the endpoint-less base api, then the use-case package
adds its endpoints with injectEndpoints and its cache tag with
enhanceEndpoints({ addTagTypes }), per that README. reducerPath stays the frozen
literal 'assetsDataApi', so one reducer, one middleware and one cache slice
still serve every use case - which the hand-scanning cache selectors depend on.

services/dada carries no extraArgument contract yet, unlike its siblings: DADA
endpoints build absolute URLs and pick prod/staging per request from an
isStaging query arg, so the base query has nothing to own. Migrating that to
extraArgument drops isStaging and touches both apps' store config, so it is
left as a documented TODO rather than smuggled into a relocation.

Layout, per the review:

  index.ts is now export * over public modules only, matching the other three
  domain/api barrels instead of enumerating ~30 named exports.

  internals/ stops being exported and now means what it says. Split by real
  consumers rather than by where things happened to live: market.ts and
  pagination.ts move out (dadaIdToMarketId has 5 app call sites,
  PartialMarketItemResponse 4), while chunkCurrencyIds, deepMergeCryptoAssets,
  emptyAssetsData, collectAllByCategory, assertDadaApiUrl and allSettled have no
  external consumers and stay in.

  collectAllByCategory and emptyAssetsData move to internals with their own
  files; the two public category accessors move to accessors.ts; request
  building and the chunked page fetch move to requests.ts. api.ts is now just
  the endpoint definitions.

The two internal helpers' characterization tests move with them from dada-client
into the api package, unchanged apart from the relative import - they were the
only remaining consumers, so keeping them where they were would have forced the
helpers to stay public. Same 246 tests as before, redistributed: 229 in
dada-client, 17 in the api package.

mergeAssetsDataPages was in the api package but the api never calls it - its
only consumers are useAssetsData and useStocksData, both hooks. Merging the
pages of an infinite query is a consumption decision, not something the api
does, so it belongs with the hooks in @features/platform-aggregated-assets.

It was also misplaced twice: its test was still in dada-client importing through
the shim, the same code-away-from-test split just corrected for chunkCurrencyIds
and deepMergeCryptoAssets.

Both move to features/platform/aggregated-assets as pagination.ts and
pagination.test.ts, assertions unchanged. The platform package gains
@domain/api-aggregated-assets for AssetsDataWithPagination, which is the correct
downward dependency; live-common's shim now re-exports from the platform
package.

Still 246 tests: 216 in dada-client, 17 in the api package, 13 here.

Completes the second half of @ysitbon's comment on api.ts:53 - 'could go on
internals and could be tested there'. The move landed in d4f207e but it was
still only exercised indirectly, through the chunked endpoint returning it for an
empty id list.

Pins the invariant that matters: it must return a fresh object every call. The
chunked lookup endpoint uses it as a reduce seed and then mutates the accumulator
in place, so a shared instance would leak merged assets between queries.

collectAllByCategory (comment api.ts:163) is left covered through its two public
accessors, which the existing suite already exercises across pages, on a failing
page and against an untrusted host - testing it directly would only duplicate
that.

features/platform/README.md prescribes components/ hooks/ helpers/ with only
files that fit no subdirectory at the root. mergeAssetsDataPages is a
cross-feature domain-aware helper, which is what helpers/ is for.

Addresses @ysitbon's comments 1 and 2 on #20345, for consistency with the rest of
the domain layer.

  fetchAt     -> DateTimeIsoSchema
  currencyId  -> union of CryptoCurrencyIdSchema and TokenCurrencyIdSchema

Feasibility was the open question and it is cheaper than expected: 0 errors in
libs/ledger-live-common, 0 in both new packages, and no brand breakage in either
app. The many DADA fixtures are untyped object literals, so branding the fields
does not reach them. Only one file needed touching - pagination.test.ts, whose
inline rate fixtures now go through InterestRateSchema.parse.

currencyId is a union, not CryptoCurrencyIdSchema alone: DADA keys interestRates
by both crypto ids (ethereum) and token ids
(ethereum/erc20/usd_tether__erc20_), so either brand on its own would mislabel
half the data.

fetchAt now rejects a malformed timestamp, so the test asserting the previous
'we deliberately do not validate this' intent is inverted rather than kept. All
four timestamp shapes DADA actually sends are covered, including its 6-digit
fractional seconds.

No runtime behaviour changes: nothing calls InterestRateSchema.parse at the api
boundary yet, which is LIVE-35232.

Fixes the live-common typecheck. Two characterization fixtures still assigned
plain strings to InterestRate.currencyId and .fetchAt, which are branded as of
the previous commit.

Both now go through InterestRateSchema.parse, so the fixtures are valid by
construction rather than cast. One fetchAt literal was '2026-07-31', which is not
RFC 3339 and would not have parsed - corrected to '2026-07-31T00:00:00Z'.

Missed locally because CI runs 'tsc --noEmit -p src/tsconfig.json
--customConditions node' while I had checked the root tsconfig, which does not
include these test files.

The branded ids and RFC 3339 fetchAt forced three characterization
fixtures to be rebuilt through InterestRateSchema.parse, which breaks the
guarantee that those tests pass unmodified through the migration.

Revert to the structural z.string() shapes so the fixtures stay byte
identical to develop. Branding lands in LIVE-35232 alongside assetsIds,
where retargeting consumers is already in scope.

Review feedback from @ysitbon on #20345.

- market.ts moves to internals/ and leaves the barrel. Nothing outside the
  package imported it: every external consumer of dadaIdToMarketId and
  PartialMarketItemResponse resolves the legacy live-common declaration, not
  this one. The two copies still need de-duplicating in the retarget tasks.
- the five single-function pure helpers become internals/utils.ts, with their
  tests merged. collectAllByCategory stays its own file: it does network I/O
  and paginates, which is not a util.
- ONE_DAY_IN_SECONDS leaves types.ts for constants.ts, written as 24 * 60 * 60.
  It stays exported because the live-common shim re-exports it.
- the mocks move under src/fixtures/. The .mock.ts suffix is kept so knip's
  '**/*.mock.*' ignore still applies, and the ./mock* export names are
  unchanged, so no consumer moves.

Review feedback from @ysitbon on #20345: use CryptoCurrencySchema rather
than parsing the id on its own.

convertApiAssets synthesises a CryptoCurrency when DADA knows an asset the
local registry does not. Only its id was validated, via
CryptoCurrencyIdSchema.parse; the rest of the object was unchecked. Parsing
the whole object through CryptoCurrencySchema validates every field and
brands the id, so the standalone parse is no longer needed.

parse rather than safeParse is deliberate: it preserves the contract the
characterization tests pin, where an unusable currency surfaces as a query
error instead of being dropped silently. It does widen what can fail the
whole response, so LIVE-35232 should convert this to per-item
drop-and-count once that telemetry exists.

Review feedback from @ysitbon on #20345: every function should be tested.

Five exported functions had no reference in any test file in the repo:
resolveBaseUrl, fetchAssetsPage, allSettled, assertDadaApiUrl, and this
package's copy of dadaIdToMarketId (only the live-common duplicate was
covered). collectAllByCategory was exercised only indirectly, through the
two accessors.

assertDadaApiUrl is the one that mattered most: it is the host guard for the
endpoints that build their own fetch instead of going through baseQuery, and
it was only reached as a side effect of untested code.

dadaIdToMarketId's trailing-separator case is characterized rather than
endorsed: '?? id' only catches null/undefined, so 'ethereum:erc20:' yields an
empty market id instead of the original.

Review feedback from @ysitbon on #20345: use getCryptoCurrencyById for the
mocks.

These fixtures are transformed-shape AssetsData, so cryptoOrTokenCurrencies
holds real CryptoCurrency entities — exactly what the registry returns. The
three hand-built ones had already drifted from the CAL: injective claimed
family "injective" and one unit where the registry says "cosmos" and two,
and bitcoin and arbitrum were similarly stale.

getCryptoCurrencyById rather than findCryptoCurrencyById on purpose: it
throws, which is what a fixture should do if the CAL ever drops the id.

The consuming assertions match on ids and assetsIds, not on presentation
fields, so nothing needed updating.

So adding a category is a list of assets rather than another hand-written
fixture.

buildCategoryResponse takes { ticker, slug?, name?, token?, market? } per
asset and derives the rest: the urn:crypto:meta-currency: ids, the token
currency and its parent network, the markets map and currenciesOrder. A new
category becomes one call.

Stablecoins collapses to a ticker list, which is all the category endpoints
consume. Stocks keeps its slugs explicit because they are not derivable from
the tickers — AAPLX is applex, not aaplx. That was caught by diffing the
serialised fixtures before and after: both are byte-identical to what the
hand-written versions produced, so the MSW handlers and integration tests
see no change.

buildCategoryResponse accumulated into Record<string, unknown>, which erased
the types the hand-written object literals used to infer. The desktop
Portfolio integration test reads a currency straight out of the map and
passes it where CryptoCurrency | TokenCurrency is expected, so it failed
desktop typecheck with TS2322.

Annotate the two maps with NetworkInfo and CryptoOrTokenCurrency instead.
Type-only change: the serialised fixtures are still byte-identical to the
pre-refactor originals.

Review feedback from @ysitbon on #20345: internal if nothing outside the
package uses it.

resolveBaseUrl and fetchAssetsPage have no consumer anywhere outside this
package, so they move to internals/requests.ts and leave the barrel.
buildAssetsQueryParams stays public — the LIVE-35224 characterization tests
import it through the dada-client shim, and those must not change.

collectAllByCategory duplicated resolveBaseUrl's getEnv branch inline; it now
calls it instead.

This is the cosmetic half of the point. Both helpers exist only because the
shared base query is configured with baseUrl: "", so every endpoint resolves
its own absolute url and the fan-out endpoint hand-rolls fetch — which is
also why assertDadaApiUrl is needed and why RTK's AbortSignal never reaches
the request. queryFn receives baseQuery as its fourth argument, so that is
fixable; both files now say so, and it is an acceptance criterion on
LIVE-35301 alongside the extraArgument migration.

The rebase onto develop conflicted on pnpm-lock.yaml in six commits. Each
was resolved by taking develop's copy, so the workspace importer entries for
the new @domain/* deps were dropped; this restores them.

Regenerating with pnpm install produced 451 insertions and 189 deletions of
unrelated peer-hash churn (react-native, expo, firebase, lumen), so instead
develop's lockfile is taken verbatim and only the four changed importer
blocks are spliced in. Against develop the diff is 51 insertions and 0
deletions, and pnpm install --frozen-lockfile succeeds.