The module-level app store makes rxNostr a process-wide singleton

`src/lib/stores/app.ts:9`

```ts
export const app = writable<{ rxNostr: RxNostr }>();
```

`NostrApp` writes to it from a reactive statement
(`src/lib/components/NostrApp.svelte:33-36`) and all twelve data components read
`$app.rxNostr` from it. Because this is module state rather than Svelte context, it
is shared by everything running in the same module instance.

**SSR cross-request leak.** Module state is shared across concurrent SSR requests on
one worker. `NostrApp`'s `$:` block runs during SSR, so request A's `rxNostr` can be
observed by request B. The demo hides this with `export const ssr = false`
(`src/routes/+layout.ts`); library consumers get no such protection and the README
does not mention it.

**Only one instance can exist.** Two ``s — side by side or nested — mean
last writer wins. The first app's descendants then use the second app's `rxNostr`
and relays, while their queries live in the first app's `QueryClient`, which *is*
context-scoped. Two scoping mechanisms that can disagree.

Determined by code reading; the QueryClient half is confirmed by the adapter using
`setContext`.

## Direction

Publish `rxNostr` through `setContext`/`getContext`, the same mechanism
`QueryClientProvider` already uses, so that scope follows the component tree.

Start with src/lib/stores/app.ts:9 and src/lib/components/NostrApp.svelte:33-36, then inspect the twelve data components that read $app.rxNostr. Compare their scope with the QueryClientProvider adapter's setContext usage. The work is done when rxNostr follows the component tree for nested or side-by-side NostrApp instances and does not leak between SSR requests.

Vom Indexierungsmodell aus dem Issue-Text verfasst.