Stores can be removed, and added from an address you type

Two gaps that were the same gap: the store list could only ever grow, and it could
only grow from what the registry happened to offer.

**Removing** uninstalls what the store installed, then deletes the store itself,
in that order. The order is the whole of it: `state.json` is the only record of
which payloads, icons and menu entries belong to a store, so deleting the home
first would strip the one thing that knows — leaving files nothing could ever
identify, least of all a later install of the same store into the same folder.
The confirmation says how many titles will go, because that is the part nobody
would otherwise expect. The token goes too; a credential for a store that is not
here is a secret kept for nothing.

The window names a *store*, never a path: the home is resolved against what a
disk scan actually found before anything is deleted, and `removeHome` refuses
anything else. That is the only guard between a bad argument and `rm -rf`, so it
has a test.

**Adding** moved to a + beside Refresh — both are actions on the whole store
rather than on one of them, and the full-width button under the list read as a
third store — and the picker now takes a catalog address as well as a listed one.
A bare host is enough and the name comes from the address; nothing else about
installing changes, which is why the typed path hands the same record to the same
method instead of growing a second one. The picker also has a Cancel now: opening
it with a store installed used to replace the grid with no way back.

`make storetest` is new, and it earned itself immediately. Removal is the only
code here that deletes a directory tree, which the smoke test cannot cover — it
runs against the real machine and would have to delete a real store to prove
anything. Two bugs on the first run:

- `http://` was accepted and became a store called *http*. The trailing slashes
  were stripped before the scheme was checked, turning `http://` into `http:` and
  then into `https://http:`, whose hostname parses as "http". The URL is rebuilt
  from the parsed form now, which also settles the trailing slash in one place.
- `STORE_ROOT` only *prepended* to the search path, so a "sandboxed" run still
  listed the real stores — despite the README saying "instead of the real one".
  Harmless while a sandbox could only add; not harmless now that it can delete.
  It replaces the search path.

The self-test needed two changes, both of which are it working: the store row is
a wrapper now, so clicking `.store-row` did nothing at all, and the footer icon
check counted exactly two named controls when there are three.

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

Makefile

@@ -36,7 +36,7 @@ BUILDER_ARGS := $(if $(STORES_API),-- --config.extraMetadata.warpEngine.registry
 
 .DEFAULT_GOAL := help
 
-.PHONY: help setup node-check build typecheck lint lint-fix check start smoke uitest test \
+.PHONY: help setup node-check build typecheck lint lint-fix check start smoke uitest storetest test \
         dist dist-mac dist-win dist-linux release publish clean distclean version
 
 help: ## List available targets
@@ -72,7 +72,7 @@ lint-fix: ## Lint and fix what can be fixed automatically
 
 # The order is deliberate: a type error explains a lint error, and both explain a
 # failing test, so the cheapest check that can fail runs first.
-check: typecheck lint test ## Type-check, lint, and run both test suites
+check: typecheck lint test ## Type-check, lint, and run every test suite
 
 start: ## Run the app against whatever store is installed
 	npm start
@@ -83,7 +83,10 @@ smoke: ## Drive the store bridge with no window at all
 uitest: ## Load the window once and report what rendered
 	npm run uitest
 
-test: smoke uitest ## Both checks
+storetest: ## Add and remove a store in a sandbox (the only code that deletes a tree)
+	npm run storetest
+
+test: smoke storetest uitest ## All three checks
 
 dist: node-check ## Package for this machine
 	npm run dist $(BUILDER_ARGS)