Add a bring-up script and a transcript dump; let nisse-dev install on its own VM (M0.2)

Development Plan M0.2.

- scripts/bringup.sh: start [REF] sets the previous run aside under
  /root/nisse-e2e/runs/, exports the ref under test and starts the agent
  as the transient systemd unit nisse-bringup, so it outlives the shell
  that started it; stop (SIGTERM, clean shutdown), status, logs, and
  collect (the journal log and a readable transcript).
- nisse_dev.dump (python -m nisse_dev.dump STATE_DB [--full]): a readable
  dump of a state store's state, pending intents and canonical log. Opens
  the store read-only, so it is safe against a live agent.
- The agent runs as root on this development VM, as it will on its own
  VM. Architecture D3/D6/D7 corrected to match the operator's intent:
  installing packages and toolchains on its own VM is class 2, recorded
  so the environment can be rebuilt (it was class 3 with provisioning an
  open question); egress names OS package mirrors. The plan's M0.2, M4.1,
  M4.2 and bring-up guards follow.

Acceptance: a smoke run started, answered status in the test room,
stopped cleanly, and collect produced the log and transcript.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

docs/Architecture.md

@@ -93,7 +93,7 @@ Every action any agent can take falls into one of three classes:
 |---|---|---|---|
 | **1. No side effects** | Observes; changes nothing outside a disposable sandbox | Reading files, querying APIs, searching, viewing logs and metrics, running a build or tests in a throwaway environment | Always allowed |
 | **2. Contained side effects** | Changes something, but the change stays within the agent's own area or has a known undo | Editing the workspace, committing to the agent's branch, opening a PR, writing the agent's own notes, starting a test container; for ops, a step with a known undo inside an approved plan | Allowed when in scope; logged and reported |
-| **3. Dangerous** | Irreversible, visible beyond the agent's own area, or outside what was agreed | Merging to a default branch, deleting data, changing a firewall, installing software on a host, contacting third parties, spending beyond a budget | Needs discussion, unless an approved plan names the exact action |
+| **3. Dangerous** | Irreversible, visible beyond the agent's own area, or outside what was agreed | Merging to a default branch, deleting data, changing a firewall, installing software on a host the agent doesn't own, contacting third parties, spending beyond a budget | Needs discussion, unless an approved plan names the exact action |
 
 **"In scope"** means within what the operator agreed to: the work item's task,
 an approved plan, a pre-approved milestone (D2), or an approved step sequence
@@ -716,12 +716,15 @@ other, often before earlier PRs are merged.
 **Toolchain preflight.** When the workspace is prepared, the agent determines what
 the project needs (from its files, e.g. `Cargo.toml`, `pyproject.toml`,
 `package.json`, or a declaration in the repo) and checks it is available. A gap is
-reported **before any planning**, with the options. The environment's toolchain
-versions become facts in the transcript (L6), so plans match reality.
+installed **before any planning**. The environment's toolchain versions become
+facts in the transcript (L6), so plans match reality.
 
-**Toolchains come from the environment, not from the agent improvising.**
-Installing software is class 3 (P3). How toolchains are provided (project dev
-containers on the VM's Docker daemon, or the VM image) is an open question (Q).
+**The agent installs what it needs on its own VM.** The VM is disposable and is
+the boundary (D7), so installing packages and toolchains there is class 2 (P3): a
+contained side effect. Every install is recorded as a fact (L6) and in the
+project's scope memory, so the environment can be rebuilt; toolchains that keep
+being needed are baked into the VM image (X4). Installing on any host other than
+its own stays class 3.
 
 **Repairing the environment is in scope.** Within a task, the agent may clean
 caches and build artifacts or reinstall project dependencies to fix a broken
@@ -771,8 +774,8 @@ a corrupt `.pyc`.
 | Class | Examples |
 |---|---|
 | 1 | Reading the repo, running tests and builds in the workspace or a test container, querying Gitea |
-| 2 (in scope) | Editing the workspace, committing to milestone branches, pushing them, opening and updating PRs, commenting on its issues and PRs, cleaning caches, installing project dependencies from package registries |
-| 3 | Merging to the default branch (unless the trust dial allows), deleting remote branches or others' work, installing system software, changing repository settings, anything outside the work item's repo |
+| 2 (in scope) | Editing the workspace, committing to milestone branches, pushing them, opening and updating PRs, commenting on its issues and PRs, cleaning caches, installing project dependencies, packages and toolchains on its own VM |
+| 3 | Merging to the default branch (unless the trust dial allows), deleting remote branches or others' work, changing repository settings, anything outside the work item's repo or its own VM |
 
 Its scope sources are the approved architecture, the build plan and each
 milestone's marking.
@@ -782,7 +785,7 @@ milestone's marking.
 - **Its own VM** (X1), with a real Docker daemon, because it builds and runs
   containers. The VM is the trust boundary for unattended command execution.
 - **Sealed:** its egress allowlist (X2) permits only LiteLLM, Gitea and package
-  registries; there is no ingress. Denial covers RFC1918 (except the specific
+  sources (language registries and OS package mirrors); there is no ingress. Denial covers RFC1918 (except the specific
   LiteLLM and Gitea addresses) and the tailnet's `100.64.0.0/10`, so it can't reach
   the NAS, Proxmox or the gateways. The inference host sits behind LiteLLM, so it is
   not a second exception.
@@ -959,8 +962,6 @@ it uses; nothing is shared between agents.
   way a misread must default to asking (L5).
 - **How far the local driver goes.** Which kinds of work it handles well and where
   a frontier driver is needed, measured on real tasks, not assumed (P7).
-- **Providing toolchains** for `nisse-dev`: project dev containers on its Docker
-  daemon, or the VM image, or both (D3).
 - **One local model for every agent.** The inference host keeps one model resident;
   different models per agent would reload weights on every switch. Preferred: one
   model good enough for every local role. Fallback: agents take turns holding the