Ask a registry which store to install

The client had our store's config URL compiled into it, which meant a second store
— or anybody else's site — needed a release of this app. It now asks
`GET /api/stores` and installs what the site offers: one record and there is
nothing to decide, several and the setup screen shows a picker.

From a record the client works the rest out. `storeRepositoryUrl` gives the
`config.json` to read, and that file stays the authority on how the store behaves;
`catalogUrl` and `name` override its `store.base_url` and `store.name`, because the
registry is what says which catalog a store is *for*. The store id — which names
the store home and the folder games land in — comes from the repository name, so
`ttg-desktop-store` becomes `ttg`.

A repository with no `config.json` still installs: the engine merges whatever it
is handed onto its own defaults, so the client writes a three-field config and the
store behaves like the default one pointed at that catalog. That was worth having
rather than an error, and it is tested.

The registry address is now the single thing about a particular site left in the
client, and `STORES_API` overrides it — which is how this was tested, against a
local endpoint serving the same payload the site returns, with one store that has a
config and one that has not. Both installed; the engine listed all ten titles with
the synthesised config.

`npm run uitest` now passes on either outcome — the grid when a store is present,
the setup gate with a populated picker when there is none — and it reports both, so
the gate cannot silently regress into an empty screen. Run with the registry
unreachable it produces the retry gate, and fails, which is the honest verdict: a
client that cannot reach the registry cannot set anything up.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -13,6 +13,10 @@ It is also **the Windows install path**. The store's own installer is
 `curl … | sh`, which Windows does not have; this app downloads the store engine
 itself, into the same folder the shell installer would use.
 
+Which store it installs is not baked in: the client asks a registry — `GET
+/api/stores` on the site — and each record says what the store is called, which
+catalog it serves and where its configuration lives.
+
 ## What it needs
 
 - **Python 3** on the machine, because the store is a Python program. The app
@@ -49,6 +53,46 @@ so there was no resource seal and Gatekeeper refused it outright rather than
 asking. `scripts/after-pack.js` signs the bundle during the build now, and the
 result verifies as `valid on disk`.
 
+## Which store it installs
+
+On first run the client fetches the registry and offers what it finds. One store
+and there is nothing to decide; several and the setup screen shows a picker.
+
+```json
+[
+  {
+    "name": "Teletype Games",
+    "catalogUrl": "https://teletypegames.org",
+    "storeRepositoryUrl": "https://git.teletypegames.org/stores/ttg-desktop-store"
+  }
+]
+```
+
+From a record the client works out the rest:
+
+- **`storeRepositoryUrl`** → the store's `config.json`, read from
+  `…/raw/branch/master/config.json`. That file is the authority on how the store
+  behaves: which platforms, which statuses, where things land.
+- **`catalogUrl` and `name`** override the config's own `store.base_url` and
+  `store.name`. The registry says which catalog this store is *for*, so it wins.
+- **the store id** — which names the store home and the folder games land in —
+  comes from the repository name: `ttg-desktop-store` becomes `ttg`. A
+  `config.json` that sets its own id keeps it.
+
+A repository **without** a `config.json` still works. The engine merges whatever
+it is handed onto its own defaults, so the client writes a three-field config and
+the store behaves like the default one pointed at that catalog.
+
+The registry address is the single thing about a particular site left in the
+client, and `STORES_API` overrides it:
+
+```sh
+STORES_API=http://127.0.0.1:8731/stores npm start
+```
+
+Adding a store is therefore a database row on the site — see its ActiveAdmin
+panel — and not a release of this app.
+
 ## Use
 
 - **Install all** fetches everything the catalog offers for this machine.
@@ -131,7 +175,7 @@ SMOKE_HOME=/tmp/sandbox-root/ttg-desktop npm run smoke
 | `main.js` | the window, the IPC, and the one-call-at-a-time guard |
 | `preload.js` | the entire surface the renderer gets — no Node reaches it |
 | `lib/store.js` | finds the store and Python, runs the CLI, parses its JSON |
-| `lib/bootstrap.js` | downloads the engine, the shared core and a config |
+| `lib/bootstrap.js` | reads the registry, then downloads the engine, the core and a config |
 | `lib/i18n.js` | the two string tables |
 | `renderer/` | plain HTML, CSS and JS — no framework, no build step |
 | `Makefile` | the named sequences; no logic of its own beyond the release |
@@ -159,6 +203,13 @@ renders the installed state, and `npm run uitest` passes with the grid rendered
 and both languages in the picker. The bootstrap download was run into an empty
 directory and the resulting store answered the bridge.
 
+The registry path was exercised against a local endpoint serving the same payload
+the site returns, with two records: one store whose repository has a `config.json`
+and one without. Both installed, and the engine listed all ten titles with the
+synthesised config. `npm run uitest` was run twice — with a store present it shows
+the grid, with none it shows the setup gate and its picker carries both names —
+and once more with the registry unreachable, which produces the retry gate.
+
 The signing was measured rather than assumed, by setting the quarantine flag on a
 copy unzipped from the release artifact: `codesign --verify --deep --strict` is
 clean, and `syspolicy_check` reports only the expected *"adhoc signed"* warning.