queryKey is the only cache identity, so two hooks sharing a key exchange data

`useReq()` passes the caller's `queryKey` straight to `createQuery()`
(`src/lib/stores/useReq.ts:43-45`). Neither `filters` nor `operator` nor the shape
of the result takes part in cache identity, but query-core dedupes strictly by key.

So two hooks given the same key share one cache entry, and the second hook's
`queryFn` is **never invoked** — its filters and operator are silently discarded
and it receives the first hook's data.

Verified on `main` (609f8ed): `useUniqueEventList(rxNostr, key, ...)` followed by
`useMetadata(rxNostr, key, 'p1')` left `useMetadata`'s `$data` holding an
`EventPacket[]` with `$status: 'success'`, and only one REQ was ever sent.
`Metadata.svelte:34-35` then takes the `{:else if $data}` branch (a non-empty array
is truthy) and passes `metadata={$data?.event}` — `undefined` — to the default
slot, so the consumer's `JSON.parse(metadata.content)` throws.

## The same hole from the other side

Filters can change while the key stays fixed. `src/routes/timeline/+page.svelte:52-62`
passes `queryKey={['timeline','feed',pubkey]}` with `filters` computed from
`pubkeysIn(contacts)`. When contacts load or change, the filters change and the key
does not, so the feed is served from cache indefinitely.

## Direction

Cache identity has to be a function of the request. Deriving the key from a
normalized form of the descriptor (filters + collection strategy + relay scope)
removes both halves and also removes a parameter callers currently have to get
right. If an escape hatch is wanted, a `namespace` that can only *partition* the
cache is safe; an explicit key that can *merge* two different requests brings this
back.