Sharing one req between hooks starves all but the last

Follow-up to #67/#72, which is where this was noticed. #72 made a `req` actually
issue its request; it did not make one `req` usable by more than one hook.

Every hook takes a `req`, and nothing says it has to be exclusive, so passing the
same one to two hooks is a natural thing to try. It doesn't work: all but the
last hook hang.

Verified on `main` (609f8ed):

```ts
const req = createRxForwardReq('shared');
useMetadata(rxNostr, ['meta'], 'p1', req); // kind 0
useUserTextList(rxNostr, ['texts'], 'p1', 10, req); // kind 1
```

```
→ REQ shared:0 {"kinds":[0],"authors":["p1"],"limit":1}
→ REQ shared:0 {"kinds":[1],"authors":["p1"],"limit":10}
→ REQ shared:0 {"kinds":[1],"authors":["p1"],"limit":10}

useMetadata status: 'loading' data: null // never resolves
useUserTextList status: settles data: ['t1']
```

## Cause

A `RxReq` carries one `rxReqId`, and every `rxNostr.use(req)` on it shares that
subscription id. Each hook emits its own filters onto the same id, so each REQ
replaces the previous one. Only the last hook's filters survive; earlier hooks
sit on a subscription that is no longer asking for what they want.

Note that the events do reach every hook — they all see the same stream — but
the relay is only sending what the last filter asked for, so the earlier hooks'
operators filter everything away.

## Direction

Each consumer needs its own subscription id. Options worth weighing:

- Derive a per-`useReq()` rxReqId from the given req rather than using it
directly, so `req.emit()` still drives the filters but each hook gets its own
REQ. Keeps the current API.
- Document `req` as single-consumer and make sharing fail loudly instead of
silently starving hooks.

Either way it wants a test that two hooks with one `req` both resolve, which is
what would have caught this.