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.

Start by tracing createRxForwardReq, RxReq, and rxNostr.use(req) through the useMetadata and useUserTextList hooks, focusing on how rxReqId and emitted filters are shared. Add a regression test using two hooks with one req and verify that both resolve; the issue's two possible API directions still need to be weighed.

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