app store: put provisioned containers under the officer root, not the user's

The install layout a machine should have, seasoned owner or not:

  ~/officerdev/
    platform/      the app
    data/          DATA_PATH
    dockers/       services the app store provisioned
    capabilities/  the file-based item store

One root, everything under it. OFFICER_ROOT derives from DATA_PATH rather than being a second variable
that has to agree with the first.

Deliberately not `~/dockers`, where a seasoned user already keeps their own estate — 47 services on this
machine. That separation buys two things. Containers the app store created are distinguishable from the
user's own structurally, rather than by a naming convention we would have to enforce and they could
break. And we never reason about someone else's compose files: the store does not scan, adopt or modify
anything outside its own directory.

That also simplifies "I already have one of these" — it is answered by the user giving a URL, never by
us finding a directory and guessing whose it is. An earlier draft had the installer adopting existing
directories, which meant reading, and potentially writing over, services Officer did not create.

This development machine predates the convention and derives an ugly-but-correct path, since the project
sits inside ~/dockers/officer.dev. Still isolated, still one root. New installs get the clean shape.

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

docs/sidecar-app-store.md

@@ -60,12 +60,11 @@ for someone who does not. The prompt is the fork.
 
 **Officer is the installer, never the owner.** Concretely:
 
-- A real compose file per service, written into a **user-owned directory**, from our template —
-  following the convention the owner already uses for 47 services in `~/dockers/`:
-  one directory per service, `docker-compose.yaml` inside, and **relative bind mounts**
-  (`./data`, `./database`, `./storage`) so configuration and data sit beside the compose file where
-  both we and the user can find them. Named volumes are used by 3 of those 47 and are the exception;
-  templates use bind mounts, always.
+- A real compose file per service, written into **`<root>/dockers/<id>/`**, from our template — using
+  the convention the owner already applies to 47 services: one directory per service,
+  `docker-compose.yaml` inside, and **relative bind mounts** (`./data`, `./database`, `./storage`) so
+  configuration and data sit beside the compose file where both we and a human can see them. Named
+  volumes are used by 3 of those 47 and are the exception; templates use bind mounts, always.
 - Started with `docker compose up -d` **as the owner**, not as officer's own identity.
 - Found again by **label** (`officer.sidecar=<id>`), not by holding a handle.
 
@@ -82,11 +81,27 @@ health checks already correct, so "install Gitea" does not become a tutorial.
 **`USER_UID` / `USER_GID` are set to the owner**, as the existing services already do. That answers the
 "do containers run as root" question: no, and this is not a new convention — it is the one in use.
 
-**An existing directory is evidence, not an obstacle.** `~/dockers/` already holds `gitea`, `memos`,
-`immich`, `jellyfin` and `invoice_shelf`. The installer must never write into a directory that exists;
-finding one is the strongest possible signal that this is the "you already have one" case, and the store
-should offer to ADOPT it — read its ports out of the compose file and write the connection — rather than
-provision a second copy or overwrite a running service's data.
+**The app store's containers are isolated from the user's own**, and that is the point of the layout:
+
+```
+~/officerdev/
+  platform/      the app
+  data/          DATA_PATH
+  dockers/       services the app store provisioned   <- exclusively ours
+  capabilities/  the file-based item store
+```
+
+`OFFICER_ROOT` is derived as the parent of `DATA_PATH` rather than configured separately — a second
+variable that must agree with the first is a second thing to get wrong.
+
+Deliberately **not** `~/dockers`, which is where a seasoned user already keeps their estate. Two
+consequences, both wanted:
+
+1. Containers the app store created are distinguishable from the user's own **structurally**, not by a
+   naming convention we would have to enforce and they could break.
+2. **We never reason about someone else's compose files.** The store does not scan, adopt or modify
+   anything outside its own directory. "I already have one of these" is answered by the user giving a
+   URL (`mode: 'existing'`) — never by us finding a directory and guessing whose it is.
 
 `[open]` Podman, for anyone wanting genuinely rootless.