An operator error discards already-rendered data and cannot be recovered from

When an operator in the pipe throws, the RxJS stream terminates permanently and
`useReq()` has no way back:

- the local `error` store is set (`src/lib/stores/useReq.ts:88-97`) and is only ever
cleared at the start of a `queryFn` run (`:50`);
- if the query had already resolved, `queryFn` will not run again on its own;
- the derived `status` prefers the local error over the query's state (`:126`), so
it reports `'error'` indefinitely.

Every component checks `{#if $error}` **before** it looks at `$data`
(`Text.svelte:32`, `EventList.svelte:32`, and the same line in the other nine), so
data that was already rendered is discarded and the component is stuck on the error
slot until something calls `invalidateQueries` by hand.

A stream that fails after delivering 50 events leaves the consumer with an error
slot and no way to show the 50 events it still holds.

Determined by code reading.

## Direction

Whether to discard already-delivered data on error is the consumer's decision, not
the library's. The result shape should be able to represent "errored, and here is
what we had" rather than forcing the two apart.

Start by reading src/lib/stores/useReq.ts, especially lines 50, 88-97, and 126, then compare the error-first rendering in Text.svelte, EventList.svelte, and the other nine components. Trace how a stream error affects previously delivered data and define a result shape that preserves both; done means consumers can choose whether to show retained data or the error state.

Written by the indexing model from the issue text.