A stream error just after the first event resolves the query while reporting 'error'

`useReq()` defers its promise resolution to a microtask
(`src/lib/stores/useReq.ts:60-70`):

```ts
next: (v) => {
latest = v;
if (fulfilled) {
queryClient.setQueryData(queryKey, v);
} else {
fulfilled = true;
queueMicrotask(() => resolve(latest));
}
},
```

`fulfilled` is set *before* the resolution actually happens. If the stream errors
between that first `next` and the microtask, the error branch (`:88-97`) sees
`fulfilled === true` and therefore does **not** reject:

```ts
error: (e) => {
console.error(e);
status.set('error');
error.set(e);
if (!fulfilled) { reject(e); fulfilled = true; }
}
```

The microtask then resolves the query successfully. The result is a state no
consumer can act on: the query is `success` and `.data` holds the first value,
while `.status` reports `'error'` and `.error` is populated. Because every component
checks `{#if $error}` first, the data is not shown.

Determined by code reading; not reproduced.

## Direction

The three stores are updated independently, which is what allows the combination to
exist at all. A single value carrying the whole state makes it unrepresentable.

Start in src/lib/stores/useReq.ts, reading the deferred resolution logic at lines 60-70 and the stream error branch at lines 88-97. Trace how the three stores are updated independently and how the first next event can race with an error. Done means the stream cannot leave query success/data alongside error status and a populated error.

Written by the indexing model from the issue text.