app store: make it work — pm2, install state, and the routes

Email installs end to end now, which was the point of picking it as tier one: no container, no external
wiring, so the machinery is exercised without the provisioning half.

Verified against the running system, not asserted:

  POST /api/app-store/email/install  -> {"status":"installed","completed":["preflight","schema","process"]}
  row                                -> email mode=config status=installed enabled=true
  pm2                                -> officer-email online
  second install                     -> all three steps skipped, process not restarted
  disable                            -> stopped

The server boots with the new router, which is the real test of the capability entry: totality.ts throws
before serve() if a mounted router has none, so booting IS the check passing.

pm2.ts shells out rather than importing pm2 as a library. PM2 is already the supervisor and the
ecosystem file is already the definition of how each process runs; a second thing in charge of that
means two supervisors disagreeing. It also means an owner can undo anything the app store did with a
command they already know. The one fact that matters: `pm2 start <name>` fails for a process PM2 has
never seen, so a first install starts from the ecosystem file with --only, and everything after goes by
name. Callers cannot know which case they are in, so startProcess decides.

Disable stops rather than deletes: a stopped process still shows in `pm2 list`, which is the honest
picture. Deleting would make a disabled sidecar indistinguishable from one never installed.

beginInstall returns the existing row instead of replacing it — that is what makes a retry a resume
rather than a re-provision — and clears lastError on the way in, so a UI never shows a stale failure
beside a working service.

The container half of enable/disable/uninstall is deliberately absent rather than stubbed silently: a
disable that leaves Immich running is a different thing from one that stops it, and the difference is
memory on the user's machine.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/capabilities/registry.ts

@@ -298,6 +298,18 @@ export const CAPABILITIES: Capability[] = [
   },
 
   // ── admin: the platform administering itself ────────────────────────────────────────────────────
+  {
+    key: 'app-store',
+    label: 'App store',
+    description: 'Install, enable and remove the sidecars this server runs',
+    // Admin, not app. Installing a sidecar starts a process on the machine and provisioning one starts
+    // containers — that is process control, not a feature a member can be granted a read of. The router
+    // gates on the owner in its own right as well; this entry is what makes the boot check pass and what
+    // keeps the surface visible in one enumeration.
+    kind: 'admin',
+    api: ['/app-store'],
+    routes: ['/app-store'],
+  },
   {
     key: 'server-admin',
     label: 'Server settings',