Improve Handing of Hardcoded Note Script Roots in MASM code

[partylikeits1983]

Problem

Accounts which create notes sometimes contain note script roots. For example:

const.BURN_NOTE_ROOT=[6407337173854817345,5626358912819151014,703918618794810515,17401169215223723177]

This creates maintenance issues when note scripts change, as the hardcoded values must be manually updated and kept in sync.

Core Issue

The fundamental challenge is determining the best way to store note script roots inside accounts that create new notes. Currently, accounts need to know script roots to create notes with the correct recipients, but hardcoding these values is brittle.

Related comments:

1. Stubbed out bridging-out flow: B2AGG note -> AggLayerBridgeOut contract -> BURN note #2023 (comment)
2. Stubbed out bridging-out flow: B2AGG note -> AggLayerBridgeOut contract -> BURN note #2023 (comment)

Proposed Solutions

1. Runtime Resolution: Use host functions to resolve script roots dynamically from the existing WellKnownNote infrastructure
2. Build-Time Generation: Generate constants at build time from compiled scripts in build.rs
3. Account Storage: Store script roots in account storage slots and update them as needed
4. Hex String Storage: Store note scripts as hex strings in account masm code, this doesn't solve the issue, it just looks slightly better (I think this is already supported)

This is a tracking issue that requires further analysis to determine the optimal approach. More time needs to be taken to evaluate the trade-offs between runtime flexibility, storage efficiency, and implementation complexity before selecting a solution.

[bobbinth]

I think the ideal solution here would be to include note constructor(s) in the note package file. For example, we could use something like this to define a note:

@entrypoint
pub proc run
    ...
end

@constructor
pub proc new
    ...
    # get the note script root
    procref.run
    ...
end

For this to work, we'll need to compile notes to libraries (rather than executables), and we'll also need to set note script entrypoint somewhere based on the @entrypoint attribute.

Then, when using this library as a dependency, we'd be able to construct notes as:

use mynote

pub proc foo
    ...
    exec.mynote::new
    ...
end

Also, cc @greenhat as maybe the compiler could generate something similar for note packages.

[partylikeits1983]

More context: #2188 (comment)

[bobbinth]

More context: #2188 (comment)

I think my proposal here was slightly different (though, of course rooted in the same underlying issue). I created #2243 for this.

[PhilippGackstatter]

@partylikeits1983 Can this issue be closed? This should be addressed by #2243 right?

[bobbinth]

Yes, I think we can. I'd create a different issue based on #2156 (comment). Basically, a note package should contain both note constructors and note script.