useReq() writes to the query cache from a subscription with no liveness guard

Once the query has settled, every subsequent event is written straight into the
cache from the subscription callback (`src/lib/stores/useReq.ts:60-62`):

```ts
if (fulfilled) {
queryClient.setQueryData(queryKey, v);
}
```

Nothing checks that the query still exists, that this subscription is still the
current one, or that anything is still observing.

- Each write refreshes `dataUpdatedAt`, so a query fed by a live subscription never
becomes stale.
- A subscription that outlives its consumers keeps writing — and `setQueryData` on a
garbage-collected key **recreates the cache entry**.
- Two live subscriptions on the same key (a retry, a refetch, or a leaked forward
req) each carry independent `scan` state and race to write different
accumulations to the same key, so `.data` flickers between them.

Related to #61, which is about the subscription outliving its consumer in the first
place; this is about the write path having no guard of its own.

Determined by code reading.

## Direction

Writes should go through something that owns the subscription's lifetime, so that a
subscription which is no longer current cannot reach the cache.

Start in src/lib/stores/useReq.ts:60-62 and trace how the subscription is created and remains current, using related issue #61 for the consumer-lifetime context. Determine how writes can be owned by the subscription lifetime without allowing stale or duplicate subscriptions to reach the cache. Done means an outdated subscription cannot recreate or refresh a cache entry, and concurrent subscriptions cannot overwrite each other's accumulation.

由索引模型根据 Issue 内容生成。