[LP] Program Registry: verified builds for LEZ programs

[fryorcraken]

Tracks LP-0023, drafted in logos-co/lambda-prize#127.

Create an RFP for a program registry providing verified builds for LEZ:
an on-chain registry that proves a deployed program's bytecode matches
published source, plus the reproducible-build tooling and attestation
flow behind it. Closest analogues are Solana's verified builds
(solana-verify + osec registry) and Etherscan source verification.

Why

Today a user or integrator looking at a deployed LEZ program has no way
to know what code it actually runs. They see bytecode. Every trust
decision — is this the real lending protocol, does this program do what
its docs claim, has the publisher swapped the implementation since audit
— currently rests on out-of-band claims.

This matters more on LEZ than on a transparent chain: privacy-preserving
programs give users less on-chain state to inspect after the fact, so
verifiability of the code itself carries more of the trust budget.

Three consumers need it:

1. Wallets and mini-apps. Showing "verified, built from
   github.com/x/y at commit abc" next to a program a user is about to
   sign for is the baseline anti-phishing signal.
2. Audited programs. An audit covers a source tree at a commit.
   Without a verified build there is nothing linking the audit report to
   the deployed artifact.
3. Integrators. Anyone composing against a program (the lending
   protocol, oracle adaptors, DEX) wants to pin against verified code
   rather than an address someone gave them.

Suggested shape

• Reproducible build toolchain for LEZ programs: pinned container image,
  deterministic compilation, documented so a third party can reproduce a
  build independently and get a matching hash.
• On-chain registry storing, per program: build hash, source repository
  and commit, toolchain version, publisher identity.
• Verifier CLI: given a program address, rebuild from the recorded source
  and confirm the artifact hash matches what is deployed.
• Handling for upgradeable programs — verification status must be tied to
  a specific deployed version and invalidated on upgrade.
• Publisher identity model: who may claim a program, and how a claim is
  authenticated.

Open questions for the RFP to resolve

• Is verification permissionless (anyone can verify and submit an
  attestation for any program) or publisher-gated? Solana's registry is
  effectively the former with a trusted-signer overlay.
• Does the registry store attestations on-chain, or on-chain hash with
  off-chain build metadata?
• Where does the verified source itself live? The registry proves a hash
  match; something still has to host the code being matched against.

Dependencies

• Requires a stable LEZ build toolchain; reproducibility is a hard
  requirement on the compiler, not something this RFP can bolt on.

References

• Solana verified builds: solana-verify, osec verified-programs registry
• Etherscan contract source verification (the weaker, non-reproducible
  analogue)