[Feature] Support program_owner as an operand.

[d0cd]

[NO NEW COMMITS ARE ALLOWED AS OF 5/27/25]

This PR:

• adds the owner Address to the Deployment and enforces that it exists and is well-formed after the migration height.
• requires the constructors exist in all programs after the migration height.
• introduces Operand::ProgramOwner to programs.
• accounts for program editions in partially_verified_transactions to handle upgrades.

Operand::ProgramOwner

• A program can reference its owner and other owners with the syntax program_owner and credits.aleo/program_owner respectively.
• The operand is only available in a constructor and finalize scope.
• Programs deployed before ConsensusVersion::V5 do not have a program owner, including credits.aleo.

Open Items

• Discussion. Can the Merkle root of the transaction be cached?
• Implementation. Hold process lock over the duration of check_transaction.
• Discussion. Consider program.owner or this.owner or enforcing <this_program.aleo>/owner to unify operands over program metadata.

[d0cd]

Earlier reviews had concerns with keeping and removing this check.

For keeping. Transaction contents can be modified, which would result in an incorrect transaction ID.

Against keeping. The constructors from_deployment and from_execution recompute the transaction ID at initialization, which involves computing the root of the transaction tree. We know from manual code review that validators use those constructors. Removing this check was needed to scale up the validator set.

[d0cd]

On looking through the code again, I could not find any constructors that did not recompute the root. If that's the case, then an ID for a Transaction in memory is correct-by-construction for an honest validator.

@reviewers do you agree?

Tangent. I noticed that get_transaction on the Ledger performs this check, making it a pretty expensive operation to do, especially for our REST API.

[vicsn]

Well for the public record, I agree, but you knew :)