Implement BOM Registry for Invoiced Order Lookup

[JEJodesty]

Implement the BOM registry that docs/NodeProductFlow.md (notes 0 & 3) describes but that doesn't exist yet
— and scope it as a lookup of Invoiced Orders, not just bare Orders.

The Order is intended to be consumed from within a "BOM" hosted on a registry — discovered via that BOM's
invoice.order_cid — rather than supplied out-of-band. Today, cats/node.py's /cat/node/init endpoint
accepts the target order_cid directly as input, standing in for the not-yet-built "look up a BOM on the
registry, then consume its Order" step. BOM CIDs also aren't yet published anywhere for future Orders to
discover.

Framing the registry's purpose narrowly around resolving a bare order_cid undersells what a BOM actually
carries. A published BOM pairs an Order with its Invoice — the CID-ed output Data and (once #
lands) Seed produced by executing that Order (docs/NodeProductFlow.md step 2b). docs/LineageOfProvenance.md
already describes chaining BOMs together via CID references so a CAT's output feeds a downstream CAT's input
across the Mesh. The registry is the missing piece that makes that chaining discoverable rather than
requiring the next Order's structure_cid/function_cid/input Data to be assembled out-of-band by whoever
submits it — i.e. the registry should resolve an Invoiced Order (Order + the Invoice it produced), not
just an Order in isolation, so a consumer can look up "what did this prior execution actually produce" and
compose their next Order's inputs from it directly.

See docs/TODO.md's "Registry lookup, not direct order_cid input" ToDo entry.

Dependencies:

• None identified yet — this is a net-new component.
• Related: the Seed-population gap (docs/TODO.md's "Seed isn't populated" entry) — an Invoiced Order
  lookup is only as complete as the Invoice it resolves, so that gap should land first or alongside this.

AC:

• A registry exists that can host/serve BOMs, addressable by CID
• The registry resolves an Invoiced Order — i.e. given a BOM CID (or invoice.order_cid), returns
  both the original Order and the Invoice it produced (output Data CID, Seed), not just the bare Order
• /cat/node/init (or an equivalent new endpoint) can look up an Invoiced Order on the registry and
  consume it, rather than requiring order_cid supplied directly in the request
• Produced BOM CIDs are published to the registry so subsequent Orders can discover and consume prior
  executions' Invoiced Orders (enabling the Mesh-wide lineage chaining docs/LineageOfProvenance.md
  describes)