Load and parse a CIP-57 blueprint from a file path.

The compiled codes the four registry pins derive from: the application whose mint arm certifies an edge, and the witness policy the three token kinds are derived from.

The four policy pins of a registry are derived from these two, so every consumer of the application — the conformance rows, the devnet end-to-end and the bounded journey — binds to one source and moves together.

#173 I2: for the OPEN registry both now come from the registry partition's own blueprint. The record keeps its name because every consumer names its fields; renaming it is a sweep this ticket does not need.

#173 A173-BOOT: the four pins of an OPEN registry, read from the registry partition's own blueprint and nothing else.

The open registry's application is open.open — parameterless, so its compiled hash IS its policy id, with no applied hash to derive (A-001 row 1; Lean openPolicyParameters = []). Its three token witnesses are witness.witness in the SAME blueprint, which moved here from the naming partition in this ticket (I2). A boot therefore consults REGISTRY_BLUEPRINT alone: no naming blueprint participates, and NAMING_BLUEPRINT need not be set at all.

Both codes are read from the SAME blueprint, so a consumer cannot silently pair an open application from one build with witnesses from another.

Find the first validator whose title starts with the given prefix and return its hash.

Find the first validator whose title starts with the given prefix and return its compiled script bytes as a ShortByteString. The hex-encoded compiledCode is decoded to raw bytes suitable for PlutusBinary.