fix(workflows): the BOM roll-up priced components from the wrong articles

[sauterbe]

A regression I shipped in #69, found while chasing a silently-ignored status filter.

Migrating the template off the raw API replaced a path-scoped call — /products/{id}/purchasePrices, correct by construction — with PurchasePrice.list filtered by product. In the flat shape query: {product: <id>}, which is what the skill documentation teaches, that filter does nothing: a core reads a filter only as filter[i][key|op|value], and Xentral answers 200 with the unfiltered collection for a query param it does not know.

So the leaf branch took its "standard supplier base tier" from a pool of arbitrary articles and wrote that as the component's purchase price. No error, no empty result — a confidently wrong number.

Measured on mvp

call	result
flat product=prd_8	50 rows across 11 different products — exactly 1 actually prd_8
bracketed product=prd_8	1 row, prd_8
bracketed product=prd_62004	0 rows — that article has no purchase price

Why my own tests missed it

The fixture scenarios hand the node an already-filtered list. They pin the arithmetic, not whether the filter reaches the wire. That is precisely the gap I have been flagging in other people's work, and it caught me.

Not dependent on the platform fix

The bracketed shape works today. agent-os fix/flat-list-filters-never-filtered additionally makes the flat shape filter properly, but this fix does not wait for it — and stays correct after it lands.

validate_graph and the render are clean; the rendered call is now:

business_entity_op("PurchasePrice", "list", {"query": {
    "filter[0][key]": "product", "filter[0][op]": "equals",
    "filter[0][value]": _ref(context, "n_pid", ""),
    "page[number]": 1, "page[size]": 50}})

Seven more templates are affected, differently

They use the same flat shape, but most also name keys that do not exist as filters at all (maxAgeDays, belowMinStock, invoiced, minOverdueDays, creditNoteCreated), or a value outside the field's options, or — in return_to_credit_note — an entity (SalesReturn) that the core does not have. Those need a redesign per template, not a shape swap, so they are deliberately not in here. Detailed per-template map in the discussion.