[AMB-2607] fix(trading): resolve duplicate offer keys in trading view cache

[wthrajat]

what was happening

the offers card was showing duplicate rows on the same side after clicking the rate or available sort. a hard refresh hid it, sorting brought it back.

why

TapTradeOffer has an id field, so apollo's InMemoryCache was normalizing it by __typename:id. the upstream amboss api returns the same id for the buy and sell sides of a listing, so the two useGetTapOffersQuery calls in TradingOffers.tsx (one purchase, one sale) clobbered each other into a single cache entity. both lists then pointed at the same merged object, and resorting made the corrupted state deterministic.

TradingPartners.tsx also queries the same field, so it was sharing the same poisoned cache entries.

fix

two small changes:

1. src/client/config/client.tsx: added TapTradeOffer: { keyFields: false } to typePolicies so apollo stops normalizing it. each query now keeps its own embedded copies, and buy/sell can't overwrite each other.
2. src/client/src/views/assets/TradingOffers.tsx: rebuilt allOffers from a Map keyed by \${_side}-\${id} as a render layer guard, so even if the api ever returns a dupe within one side the ui stays clean.

repro before the fix

1. open the trading page on a node where the offers card has data
2. click the rate column header, then click available
3. duplicate rows for the same offer appear on the same side
4. hard refresh clears it until you sort again

verify

hard refresh after pulling (the ApolloClient is cached at module scope in client.tsx, so the typepolicy only takes effect on a clean boot). then sort freely, no dupes.

bug

[wthrajat]

Checking if that can be solved in our Magma API's layer better.