Add the BuildEase demo-data reference, read from mev source

Overlay 3 said what not to install and gave no shape for what to build instead, so
the staging script was being written from scratch each time against models nobody
had the field list for.

reference/buildease_demo_data.md carries the QTO -> sale order -> project ->
progress statement -> invoice graph: required fields per model, creation order,
which transitions are button methods rather than writes, and the seven guards that
stop the chain mid-build (missing product blocks conversion; the SO will not confirm
while the QTO is in QTO state; no statement until the QTO is Confirmed; statement
periods may not overlap; a QTO-linked order cannot be copied at all).

All of it read from callista-tools/mev @ 43c2e19 and Odoo 19 core, nothing inferred.
The config block is labelled illustrative because build_demo.py cannot execute it —
it is a per-engagement template that silently ignores keys it does not implement,
which is now an error upstream in callista-odoo-demo.

Two purge corrections fall out of the source, both loosening rules that were stricter
than reality:
- Deleting the take-off already deletes its sale order; unlink() cascades.
- A take-off with no sale order cancels and deletes normally. cancel() writes the
  state directly and no-ops on the empty order, since Odoo 19's action_cancel has no
  ensure_one(). The convert-to-quotation-first workaround was unnecessary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SKILL.md

@@ -60,6 +60,15 @@ dependencies that bundle used to drag in (`sale_management`, `project`, `purchas
 `sale_timesheet`, `industry_fsm`, `accountant`, `uom`) still need installing — route them
 from the pain table, not from the demo bundle.
 
+**Read `reference/buildease_demo_data.md` before writing the staging script.** It carries
+the QTO → sale order → project → progress statement → invoice object graph from mev source:
+required fields per model, creation order, which transitions are button methods rather than
+writes, and the seven guards that will otherwise stop the chain mid-build.
+
+`scripts/build_demo.py` is a per-engagement template, not an engine — it knows nothing about
+take-offs, and it ignores config keys it doesn't recognise. Adapt it; do not assume a
+BuildEase-shaped config will drive it.
+
 ## Overlay 4 — Purge chain
 
 *Applies at:* **Purge test residue**, replacing the generic chain.
@@ -72,10 +81,17 @@ transient wizard rows → statements (cancelled only, newest first) → invoices
 The generic traps still apply. These are the BuildEase-specific ones, each of which cost
 a debugging round:
 
-- **A take-off with no sale order cannot be deleted at all.** Its state is derived from the
-  order, so there is nothing to cancel. Convert it to a quotation, cancel that, then delete.
+- **Cancel before deleting, on all three.** `unlink()` refuses unless `quantity.take.off` is
+  `cancel`, a QTO-linked `sale.order` is `cancel`, and `sale.progress` is `cancelled`.
+- **Deleting the take-off deletes its sale order** — `quantity.take.off.unlink()` unlinks
+  `sale_order_ids` first. The take-off is the handle for both.
+- A take-off with **no** sale order still cancels and deletes normally: call `cancel()`, which
+  writes the state directly and no-ops on the empty order. No convert-to-quotation dance.
+- **Statements cancel newest-first only** — `action_cancel` refuses unless it is the last one,
+  and `action_draft` refuses if a newer statement exists.
 - Leftover `add.dynamic.article.template.line` rows pin take-offs. Clear them first.
-- Statements cancel newest-first only.
+
+Full field-level detail, including the guards, is in `reference/buildease_demo_data.md`.
 
 ## Overlay 5 — Follow-through framing