A refetch restarts accumulation from an empty seed, collapsing list data

`useReq()` builds its observable once (`src/lib/stores/useReq.ts:42`) and subscribes
to it inside `queryFn` (`:52-69`). Every fetch attempt therefore re-subscribes,
which restarts `scanArray()` / `scanLatestEach()` from their seeds, and the value
the promise resolves with overwrites whatever the cache had accumulated.

Verified on `main` (609f8ed): with a list holding `['a1','a2']`, a
`refetchQueries` followed by a single event left `$data === ['b1']`.

The mock relay showed **no second REQ** — rx-nostr dedupes the identical subId
while the first subscription is still open — so the second subscription only sees
events from that point on. The collapse is not even compensated by re-fetching the
backlog.

This is reachable in normal use: `refetchOnWindowFocus` is left at its default
`true` (filed separately), so returning to the tab more than `staleTime` after a
request settles is enough.

## Direction

The accumulation strategies used here (dedupe by id, latest per pubkey, latest per
address) are all idempotent and monotonic — replaying an event changes nothing, and
a newer event can only add or replace. If a re-request feeds the *existing*
accumulator instead of a fresh one, this class of failure cannot occur: a refetch
can only grow or update the result.

Start in src/lib/stores/useReq.ts at lines 42 and 52-69, then trace how scanArray() and scanLatestEach() receive their seeds across subscriptions. Reproduce the refetchQueries scenario with accumulated list data and verify that a refetch preserves existing items while still accepting later events; the result should no longer collapse to only post-refetch events.

Vom Indexierungsmodell aus dem Issue-Text verfasst.