Samples Source Providers

## Problem

Sample scenes come from one static file: `app/config/sample-scenes.ts`. This file holds a hardcoded list. To add a new sample, we must edit code and ship a new release.

Each sample also matches one specific openEO backend. A sample sets a `collectionId` (e.g. `sentinel-2-l2a`) and band names (e.g. `reflectance|b04`). These names come from the backend set in `appConfig.openeoApiUrl`. If the app points to a different backend, that backend may use other collection IDs or band names, and the sample breaks.

We want to load samples from more than one source, and match samples to the connected backend.

## Goal

Add a provider system for sample scenes. Each provider fetches scenes from one source. The app combines scenes from all active providers. This design lets us add new sources later, without more hardcoded lists.

## Proposed design

Define one common interface, for example `SampleSourceProvider`:

- `id`: a short name for the provider (e.g. `json`, `apex`, `openeo-udp`)
- `listScenes(): Promise`: returns the scenes from this source

Keep the current `SampleScene` type (`app/types/index.ts`) as the common shape. Each provider must map its own data to this shape.

Add a small registry that:

- Holds the list of active providers, set in config
- Calls `listScenes()` on each active provider
- Merges the results into one list
- Skips a failed provider instead of failing the whole app (log the error, keep the other scenes)

Providers may fetch data over the network. This makes scene loading asynchronous. Today, `SAMPLE_SCENES` is a static array, and `scene-grid.tsx` / `editor-page.tsx` read it directly. These consumers need a loading state, for example through a `useSampleScenes()` hook.

**Backend matching.** A scene only works on the backend it was built for (its `collectionId` and band names must exist there). The registry should know the active backend (`appConfig.openeoApiUrl`) and drop scenes that do not match it. Exact matching rules (e.g. tag each scene with a backend URL, or check collection/band names against the live STAC catalog) need more thought, but each provider should be able to say which backend a scene belongs to.

## Providers to build

### 1. `jsonProvider` (first, this issue)

Wraps the current static list. Reads local scene definitions from a config file (JSON or TS). Keeps the current thumbnails, algorithm code, and default bands. This provider ships with the app and makes no network call.

The config file may hold samples for more than one backend. The provider should tag each sample with the backend it targets, so the registry can filter by the active backend.

### 2. `apexProvider` (future, follow-up issue, related to #80)

Fetches entries from the APEx Algorithm Catalogue (https://algorithm-catalogue.apex.esa.int/) and maps each one to a `SampleScene`.

This also covers the reverse flow from #80 ("open this graph in openEO Studio" from the APEx catalogue): the same mapping logic can turn an incoming APEx graph link into a scene the editor can open.

### 3. `openEOUdpProvider` (future, follow-up issue)

Fetches the public user-defined processes (UDPs) from the configured openEO backend (`appConfig.openeoApiUrl`, in `app/config/runtime.ts`), through the `GET /process_graphs` endpoint. Maps each public UDP to a `SampleScene`.

Note: the app does not call this endpoint today. This provider is the first user of it. Since it reads straight from the connected backend, its scenes always match that backend, with no extra check needed.

## Out of scope for this issue

- Full implementation of `apexProvider` (#80) and `openEOUdpProvider` (tracked as follow-up issues)
- Caching or refresh strategy for remote providers

Start with app/config/sample-scenes.ts and the SampleScene type in app/types/index.ts, then inspect how scene-grid.tsx and editor-page.tsx read SAMPLE_SCENES. Implement the first jsonProvider and registry around the proposed interface, including provider failures and active-backend filtering, and update consumers for asynchronous loading. Done means the current samples still appear through the provider system without network access.

Written by the indexing model from the issue text.