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/Development-Plan.md

@@ -80,10 +80,9 @@ test Matrix room, a budget-capped LiteLLM key; configuration in `~/nisse-e2e/`.
 - **A bring-up run on this box ends each phase** where it can be run live. What it
   finds is filed as issues and fixed before the next phase starts, or explicitly
   deferred.
-- **Bring-up guards on this box** (it isn't the sealed VM): the agent runs as an
-  unprivileged user, touches only test resources, and keeps today's structural
-  gates on in its bring-up configuration until the classifier and trust dial are
-  proven (Phase 3).
+- **Bring-up runs on this development VM,** as root, like production. Guards: it
+  touches only test resources, and keeps today's structural gates on in its
+  bring-up configuration until the classifier and trust dial are proven (Phase 3).
 - **This plan is revised as we go:** a milestone's scope may move once work shows
   its real shape, recorded here in the same PR.
 
@@ -100,10 +99,15 @@ test Matrix room, a budget-capped LiteLLM key; configuration in `~/nisse-e2e/`.
   section table this plan carried for the purpose.
 - Acceptance: `grep` finds no reference to the old spec or its section numbers.
 
-**M0.2 A bring-up script, and an unprivileged agent user on this box.** *Pre-approved.*
-- One script: set aside the previous run's state, workspace and log; start the agent
-  as an unprivileged user; collect logs and the transcript afterwards.
-- Acceptance: a smoke run starts, answers `status`, and stops cleanly as that user.
+**M0.2 A bring-up script.** *Pre-approved.*
+- `scripts/bringup.sh`: set aside the previous run's state, workspace and log;
+  export the ref under test; start the agent as a systemd unit, so it outlives the
+  shell that started it; collect the log and a readable transcript
+  (`python -m nisse_dev.dump`) afterwards.
+- The agent runs as root on this development VM, as it will on its own VM in
+  production (D7), so installing packages works as it will there.
+- Acceptance: a smoke run starts, answers `status`, stops cleanly, and `collect`
+  produces the log and transcript.
 
 ### Phase 1 — Foundations the new loop needs
 
@@ -211,11 +215,13 @@ on, then deliberately loosened in the bring-up configuration.
 
 ### Phase 4 — The environment
 
-**M4.1 Toolchain preflight.** *Pre-approved.* Detect, check, report before planning;
-toolchain facts in the transcript (D3).
+**M4.1 Toolchain preflight.** *Pre-approved.* Detect what the project needs, check
+it, and install what's missing before planning; toolchain facts in the transcript
+(D3).
 
-**M4.2 Providing toolchains.** *Needs discussion.* Decide dev containers vs the VM
-image (Q), then build it.
+**M4.2 Recording installs.** *Pre-approved.* Every package or toolchain the agent
+installs is recorded as a fact and in the project's scope memory, so the
+environment can be rebuilt; recurring ones are noted for the VM image (D3, X4).
 
 **M4.3 Environment repair.** *Pre-approved.* The driver may clean caches and
 reinstall project dependencies within a task, and reports it (D3).