feat: scenarios for curator/memo-inbox/pi-grok, deploy and backup tooling

Scenarios
- memo-inbox: mirrored by copying; the live directory was not moved or modified
  and the service was not restarted. All four tracked files match byte for byte
  (pi-diff.sh reports SAME). Marked deploy = "mirror" so deploy-scenario.sh
  refuses --apply: applying a mirror would invert the direction of truth and
  could change a service in daily use.
- curator: target configuration, not yet deployed. .pi/SYSTEM.md replaces pi's
  coding-assistant prompt; durable role text is in .pi/APPEND_SYSTEM.md;
  profile.toml is the single source of truth for the launch contract.
- pi-grok: registered only. It is genuinely a coding agent, so the isolation
  baseline does not apply in full.

Corrections to the documentation, found by testing rather than by reading
- AGENTS.override.md does NOT block parent-directory context files; it only
  shadows its own directory. Verified: with an override file in the workspace, a
  marker in /tmp/AGENTS.md still reached the system prompt. The only effective
  switch is --no-context-files, so durable role text must live in
  .pi/APPEND_SYSTEM.md, which is a system-prompt file and unaffected by -nc.
  Verified end state: no coding-assistant framing, no pi-docs block, own
  identity and role text present, no parent pollution, only own skills/tools.
- PI_CODING_AGENT_DIR isolates settings/models/auth/trust/extensions/skills/
  prompts/themes under the agent directory -- stronger than the --no-* flags
  because it also repoints credentials -- but does NOT cover ~/.agents/skills.
  Measured: find-skills, modsearch and summarize still leak. So it complements
  --no-skills rather than replacing it.
- --append-system-prompt accepts a file path, which pi-grok relies on.
- cwd is what anchors .pi discovery: a probe that forgot cwd silently lost
  .pi/SYSTEM.md and kept the coding-assistant persona.

Tooling (all dry-run by default; none of them restarts a service)
- pi-diff.sh: compares tracked config against the live install in both
  directions, with a key-redacted comparison for models.json
- deploy-scenario.sh: installs a workspace and renders profile.toml into
  .pi/launch.json, then checks that every referenced path exists
- deploy-runtime.sh: renders models.json from its template, refusing placeholder
  or missing keys. Verified byte-identical to the live file
- pi-backup.sh / pi-restore.sh: archives outside the repo, sha256 manifest
  verified before any restore, live paths preserved rather than overwritten

Fixed while testing: pi-backup.sh compared the destination against the repo root
literally, so a relative --dest ./backups wrote credential archives into the work
tree. Now canonicalised with realpath; ./backups, an absolute in-repo path and
./docs/../backups are all refused.

docs/pi-runtime-notes.md

@@ -156,17 +156,48 @@ Probe evidence:
 | isolation flags only | true | true | false | 2619 |
 | `+ .pi/SYSTEM.md + --approve` | **false** | **false** | **true** | **960** |
 
-## 9. Context files are loaded from every parent directory
+## 9. Context files are loaded from every parent directory, and `AGENTS.override.md` does not stop that
 
 Load order: `~/.pi/agent/AGENTS.md`, then each parent directory walking up from
-cwd, then cwd. `AGENTS.override.md` replaces `AGENTS.md`/`CLAUDE.md` **for that
-directory only**; other directories still layer normally.
+cwd, then cwd.
+
+`AGENTS.override.md` replaces `AGENTS.md`/`CLAUDE.md` **for its own directory
+only**. Parent directories still layer normally — the docs say so explicitly
+("Context files from other directories still layer normally") and it is easy to
+get this wrong.
+
+Probed: with `AGENTS.override.md` present in the workspace and a marker file at
+`/tmp/AGENTS.md`, the marker **still appeared** in the system prompt.
+
+| Configuration | parent `/tmp/AGENTS.md` in prompt |
+|---|---|
+| workspace has `AGENTS.override.md` | **yes** |
+| `--no-context-files` (`-nc`) | no |
 
 So a stray `~/AGENTS.md` or `~/pi-workspaces/AGENTS.md` silently contaminates
-every scenario rooted below it. Neither existed on this host as of 2026-08-27,
-but nothing prevents one from appearing. Use `-nc` plus an explicit
-`SYSTEM.md`, or an `AGENTS.override.md` in the workspace, to make the
-personality deterministic. Probed: `-nc` removes the AGENTS.md marker.
+every scenario rooted below it, and an override file will not save you. Neither
+existed on this host as of 2026-08-27, but nothing prevents one from appearing.
+
+**The only way to make the personality deterministic is `-nc`.** Since that also
+drops the workspace's own context file, the durable role content has to move into
+`.pi/SYSTEM.md` and `.pi/APPEND_SYSTEM.md`, which are system-prompt files rather
+than context files and are therefore unaffected by `-nc`.
+
+Verified combination — no coding-assistant framing, no pi-docs block, own
+identity and role text present, parent pollution absent, only the scenario's own
+skill listed:
+
+```
+--no-builtin-tools --no-extensions -e <ext> --no-skills --skill <dir>
+--no-prompt-templates --no-themes --approve -nc
++ .pi/SYSTEM.md + .pi/APPEND_SYSTEM.md
+```
+
+Note also that `cwd` is what anchors this discovery: launching pi from the wrong
+working directory silently drops `.pi/SYSTEM.md` and every workspace context
+file. A probe that forgot `cwd` produced a 2601-character prompt with the
+coding-assistant persona intact; with the correct `cwd` it produced 4082
+characters with the persona replaced.
 
 ## 10. Project trust gates `.pi/`, and CLI `-e` bypasses it
 
@@ -187,6 +218,55 @@ Non-interactive modes (`-p`, `--mode json`, `--mode rpc`) never prompt; they use
 `-e /path/to/ext.ts` avoids the trust question entirely, which is the most
 robust option for a systemd-managed gateway.
 
+## 10b. `PI_CODING_AGENT_DIR` isolates the agent directory — but not `~/.agents/skills`
+
+```
+PI_CODING_AGENT_DIR   Override the config directory; default is ~/.pi/agent
+```
+
+This is the strongest isolation lever available, and it is stronger than the
+`--no-*` flags because it repoints **credentials and trust** as well as
+resources. The `pi-grok` scenario on this host uses it:
+
+```sh
+export PI_CODING_AGENT_DIR="$PI_GROK_HOME/.pi-agent"
+```
+
+Measured, with a marker extension planted in both directories and no `--no-*`
+flags at all:
+
+| Resource | default agent dir | `PI_CODING_AGENT_DIR=<iso>` |
+|---|---|---|
+| `<dir>/extensions/*` | `DEFAULT_EXT_LOADED` | `ISO_EXT_LOADED` — **isolated** |
+| `<dir>/skills/*` | *(none)* | `iso-skill` present — **isolated** |
+| `~/.agents/skills/*` | `find-skills, modsearch, summarize` | `find-skills, modsearch, summarize` — **still leaks** |
+
+So it isolates `settings.json`, `models.json`, `auth.json`, `trust.json`,
+`extensions/`, `skills/`, `prompts/` and `themes/` **under the agent directory**,
+but `~/.agents/skills/` is a separate discovery root that it does not touch.
+
+Practical consequences:
+
+* Use `PI_CODING_AGENT_DIR` per scenario when scenarios should not share
+  provider credentials, trust decisions or model defaults. It is the only way to
+  stop one scenario's `auth.json` from being readable by another's agent.
+* It does **not** replace `--no-skills`. Keep the loading flags as well.
+* A companion variable exists: `PI_CODING_AGENT_SESSION_DIR`, overridden by
+  `--session-dir`.
+
+## 10c. `--append-system-prompt` accepts a file path
+
+The help text says "Append text **or file contents**". `pi-grok` relies on this:
+
+```sh
+--append-system-prompt "$PI_GROK_HOME/AGENTS.md"
+```
+
+This is a third way to inject durable role text, alongside
+`.pi/APPEND_SYSTEM.md` and `AGENTS.md`. Unlike a context file it is immune to the
+parent-directory walk, and unlike `.pi/APPEND_SYSTEM.md` it needs no project
+trust. Useful when the role text must live outside the workspace.
+
 ## 11. User-global resources leak into every scenario
 
 Probed with no isolation flags, from an unrelated workspace, the skills list was: