useReq() counts write-only relays as usable, so the request stalls

`useReq()` decides whether any relay is usable with an unfiltered call
(`src/lib/stores/useReq.ts:25`):

```ts
if (Object.keys(rxNostr.getDefaultRelays()).length === 0) {
```

`getDefaultRelays()` returns write-only relays too
(`node_modules/rx-nostr/src/rx-nostr/rx-nostr.ts:115-146`), but `rxNostr.use()`
targets `defaultReadableConnections` (`rx-nostr.ts:308`), which for a write-only
set is empty.

Verified on `main` (609f8ed) with
`setDefaultRelays([{ url, read: false, write: true }])`: the check saw one relay and
took the normal path, the mock relay received zero messages, and `$status` stayed
`'loading'`.

In that state `targetConnections` is empty, so rx-nostr's normal completion path
(all target relays EOSE'd or down) never fires either. The only remaining escape is
`completeOnTimeout(eoseTimeout)` — and that operator sits *before* `filterBySubId`
in the pipeline (`rx-nostr.ts:437-441`), so its timer is reset by any event on the
global `event$`, not by this subscription. In a test with no other traffic it fired
after 30 s; in an app with other active subscriptions it may never fire.

## Direction

Count read-capable relays only (`getDefaultRelays({ filter: 'read-all' })` or
equivalent). A request-level timeout owned by nosvelte is a separate need, since
rx-nostr's own timeout cannot be relied on here.

Start at src/lib/stores/useReq.ts:25 and inspect the getDefaultRelays filtering options and readable-connection behavior in node_modules/rx-nostr/src/rx-nostr/rx-nostr.ts:115-146,308,437-441. Reproduce the write-only relay case described in the issue, then verify that read-capable relay handling and completion behavior work as expected. The separate request-level timeout is an additional design task.

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