Add dry-run apply activation plan

docs/architecture.md

@@ -107,6 +107,16 @@ python3 -m ampg --config gateway.toml doctor --platform android-termux
 This keeps the same gateway config portable across a VPS, laptop, old phone, or manual
 render-only environment while making daemon ownership decisions explicit.
 
+## Activation plan
+
+`ampg apply --dry-run` turns daemon status and generated config artifacts into an ordered
+activation sequence. Each enabled protocol gets output, artifact, daemon, and health
+steps. Blocked steps stop the command before any live apply path can touch services.
+
+The dry-run command is intentionally stricter than `doctor`: missing generated output is
+blocked during activation, because AMPG must not point a transport at an unbuilt output
+root.
+
 ## Interaction boundary
 
 v1 is static-first, but the architecture reserves a path for interactive applications.

docs/daemon-management.md

@@ -39,6 +39,8 @@ config artifacts.
 ```sh
 python3 -m ampg --config gateway.toml status
 python3 -m ampg --config gateway.toml doctor
+python3 -m ampg --config gateway.toml apply --dry-run
+python3 -m ampg --config gateway.toml apply --dry-run --write-artifacts
 python3 -m ampg --config gateway.toml doctor --platform android-termux
 ```
 
@@ -49,6 +51,12 @@ adapter, installed/running daemon probe, action, and policy result.
 daemon policy feasibility. It exits nonzero only for errors; missing build output is a
 warning so operators can run it before the first build.
 
+`apply --dry-run` prints the activation sequence for each enabled protocol: generated
+output readiness, config artifacts to review, daemon action, and post-apply health
+checks. It exits nonzero when any step is blocked. `--write-artifacts` writes reviewable
+config snippets to the configured plan root but still does not install or reload
+services.
+
 Platform providers describe how AMPG may supervise managed daemons:
 
 - `linux-systemd`: system service management after approval.