docs(template): §13 gains a teardown step, §15 gains its evidence line

Three drills, three orphaned hub customers -- drill-r50, sess-c, sess-d -- because
§13 covered the clean-tree gate, build/deploy, live validation and the STOP point
and said nothing about teardown at all. Layers 1 and 2 (the VM and its volumes; the
host's reclaimed space) get remembered because they are visible on the box. Layer 3,
the hub-side customer or appliance record, is invisible from there and has been
missed every time -- sess-c was not even recorded by its own report, so the record
claimed a clean teardown that had not happened.

§13: a Teardown subsection at the end, before §14. All three layers, with the hub
layer requiring an EXPLICIT disposition -- deleted, retained as a fixture with the
reason, or gate-blocked with the command recorded -- because silence is how
drill-r50 became simultaneously a blocked customer and the only drift fixture.
Cites runbooks/target-selection.md for which machine to provision on rather than
restating it.

§15: deliverable 8 demands the evidence for all three layers and names the failure
it prevents; the former 8 (Observations) becomes 9. No section renumbered, §13/§15
not restructured, author checklist untouched.

Part 1 of the R-116 join task, committed alone and before any Go file is opened --
the code half ends in a live run and live runs have stalled twice, while the record
work is unconditional.

documentation/PROMPT-TEMPLATE.md

@@ -429,6 +429,23 @@ automation is **NOT available** on DooPlex — endpoint-level is the standard me
 live destructive op or migrate real customer data** — that is the supervised [Bx] step. Throwaway
 marker dirs under a scratch `/mnt` path are OK only if they touch no enrolled customer data.
 
+**Teardown.** A run that provisions anything owns its removal. Three layers, and the third is the one
+that gets missed:
+
+1. **The machine** — the VM or guest and its volumes, deleted.
+2. **The host** — `pvesm status` before and after, and the space actually returned.
+3. **The hub** — the customer or appliance record the run created. State its disposition
+   **explicitly**: deleted; or retained as a fixture **with the reason**; or blocked by the
+   ONLINE→DOWN delete gate **with the command recorded for later**. Silence is how `drill-r50` became
+   both a blocked customer and the only drift fixture.
+
+**Precedent: three drills, three orphaned customers** — `drill-r50`, `sess-c`, `sess-d`. `sess-c` was
+not recorded by its own report, so the record said the teardown was clean when it was not. Layers 1 and
+2 are the ones that get remembered because they are visible on the box; layer 3 is invisible from there
+and has been missed every time.
+
+Which machine to provision on in the first place: **`documentation/runbooks/target-selection.md`**.
+
 ---
 
 ## 14. Implementation order
@@ -459,7 +476,11 @@ Report MUST include:
 6. **Deployed versions** + `docker ps` / agent-service / hub-pod verification output.
 7. **NOT yet live-validated — awaiting supervised [Bx]:** explicit list (the real
    put-data → operate → integrity flow).
-8. **Observations:** out-of-scope items noticed — documented, NOT acted on.
+8. **Teardown evidence — all three §13 layers**, if the run provisioned anything: the machine deleted,
+   `pvesm status` before/after with the space returned, and the **hub-side record's disposition named**
+   (deleted / retained-with-reason / gate-blocked-with-the-command). A run that provisioned nothing says
+   so. "Teardown clean" without layer 3 is not a report — it is the `sess-c` failure.
+9. **Observations:** out-of-scope items noticed — documented, NOT acted on.
 
 ---