fix(workflows): the recursive BOM templates run through the entity core

[sauterbe]

These two were the last shipped content still reaching Xentral's HTTP API directly — and that is what kept WORKFLOW_FORBID_RAW_ERP disarmed in agent-os #100. Arming it would have made init_from_template fail on templates we publish ourselves.

With this merged and vendored, the armed gate rejects 0 of the shipped templates.

Not just a node-type swap

The old graph read the components (/products/{id}/parts) and the product itself (/products/{id}) as two calls on two branches. The core carries the bill of materials on the product record — bom.items, filled on a single read — so one Product.read serves both branches and n_parts + n_artikel collapse into n_prod.

The leaf branch loses its extra read too: PurchasePrice rows carry isStandardSupplier themselves, so nothing needs to fetch the product just to compare supplier ids.

before	after
bauteile.data	produktDetail.bom.items
Bauteil.amount	Bauteil.quantity
artikel.data.calculatedPurchasePrice.price.amount	produktDetail.prices.purchase.amount
produkte.data	produkte (ADR-0002: a list node's output IS the array)

The read node is produktDetail, not produkt

The driver loop already binds Produkt. Rendering the first attempt showed the renderer silently resolving the collision by renaming the read to produkt2 — while the condition still read produkt, and the component loop bound to the driver's items instead of the bill of materials. Both branches would have run green on the wrong data.

Caught by reading the generated Python. That is the verification step here, not the JSON diff — the JSON looked perfect.

source: "calculated" is load-bearing

It is what makes the core emit hasCalculatedPurchasePrice: true. Without it the same number lands as a manual price — same figure, different meaning to the ERP.

Measured, not read off the schema: the schema marks prices.purchase.source read-only, but map_write accepts it and only that value sets the flag. Filed separately as a core finding; these templates depend on the measured behaviour.

One behaviour fix

On a tie at the smallest tier quantity the leaf now takes the cheaper row — which is what the description has always promised ("der günstigste Basis-Staffelpreis"). Both the old version and my first migrated one took whichever row the API returned first, so the result depended on upstream ordering.

Verification

Both rendered workflows executed against entity fixtures — a two-level bill, 2 × prd_2 + 3 × prd_3:

• supplier-priced: each leaf resolves to 5.00 — the standard supplier's base tier, not the cheaper 1.00 row of an alternative supplier and not the 10-tier 4.00. Parent writes {"prices": {"purchase": {"amount": "25.0", "currency": "EUR", "source": "calculated"}}}.
• calculated-EK: leaves resolve to their stored 7.00 → "35.0".
• no write is traced for either leaf, so "purchased articles are only read, never modified" still holds.

Plus: validate_graph clean (no errors, no warnings) and check_workflow clean in both locales for both templates.

Prose reconciled

Including the runtime budget, which genuinely changed: one core read fetches stock, bill of materials, sale prices and properties together. They run in parallel, but it is several calls against the rate limit instead of one — so a run is now budgeted at ~50–100 articles rather than ~100–200. Stated rather than quietly inherited.

Follow-up, not in here

bom_cost_rollup.json (the non-recursive sibling) is fiction against this core: it lists a BillOfMaterials entity that does not exist, filters Product on isBom which is not filterable, and reads purchasePrice / writes calculatedPurchasePrice as flat fields the model does not have. It passes the raw-ERP gate because it is already business-entity shaped — it is simply wrong. Worth its own PR.