chore: Close gap in account memory layout

[Copilot]

Plan to Close Account Memory Gap

• Update memory layout constants in memory.rs:
  • Update ACCT_PROCEDURES_CALL_TRACKING_OFFSET from 2084 to 1060
  • Update NUM_ACCT_STORAGE_SLOTS_OFFSET from 2340 to 1316
  • Update ACCT_STORAGE_SLOTS_SECTION_OFFSET from 2344 to 3360
  • Remove unused ACCT_INITIAL_STORAGE_SLOTS_SECTION_OFFSET constant (only used in MASM)
  • Update the account layout table to match the new layout
  • Update other tables to use new format (start address + size)
  • Fix storage slot section sizes to properly support 255 slots max (2040 elements each)
• Update memory layout constants in memory.masm:
  • Update ACCT_PROCEDURES_CALL_TRACKING_OFFSET from 2084 to 1060
  • Update NUM_ACCT_STORAGE_SLOTS_OFFSET from 2340 to 1316
  • Update ACCT_STORAGE_SLOTS_SECTION_OFFSET from 2344 to 3360
  • Update ACCT_INITIAL_STORAGE_SLOTS_SECTION_OFFSET from 4384 to 1320
• Run tests to verify changes
  • miden-standards tests pass (52 tests)
  • Build succeeds for all targets
• Run linters to ensure code quality
  • Clippy passes
  • Format check passes
• Request code review
  • Address review feedback (added missing constant, fixed slot sizes)
  • Remove unused constant from Rust code
  • Add changelog entry
• Resolve merge conflicts after rebase on main

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Close gap in account memory layout</issue_title>
<issue_description>
After #2162, we have the following account layout in kernel memory:

miden-base/crates/miden-lib/src/transaction/memory.rs

Lines 31 to 51 in a16d076

	// Relative layout of one account
	//
	// Here the "end pointer" is the last memory pointer occupied by the current data
	//
	// | Section | Start address, pointer (word pointer) | End address, pointer (word pointer) | Comment |
	// | ------------------ | :-----------------------------------: | :---------------------------------: | ----------------------------------- |
	// | ID and nonce | 0 (0) | 3 (0) | |
	// | Vault root | 4 (1) | 7 (1) | |
	// | Storage commitment | 8 (2) | 11 (2) | |
	// | Code commitment | 12 (3) | 15 (3) | |
	// | Padding | 16 (4) | 27 (6) | |
	// | Num procedures | 28 (7) | 31 (7) | |
	// | Procedures roots | 32 (8) | 1_055 (263) | 256 procedures max, 4 elements each |
	// | Padding | 2_080 (520) | 2_083 (520) | |
	// | Proc tracking | 2_084 (521) | 2_339 (584) | 256 procedures max, 1 element each |
	// | Num storage slots | 2_340 (585) | 2_343 (585) | |
	// | Storage slot info | 2_344 (586) | 4_383 (1095) | 255 slots max, 8 elements each |
	// | Initial slot info | 4_384 (1096) | 6_423 (1545) | Only present on the native account |
	// | Padding | 6_424 (1545) | 8_191 (2047) | |
	//
	// Storage slot info is laid out as [[0, slot_type, slot_id_suffix, slot_id_prefix], SLOT_VALUE].

Due to reducing the elements per procedure from 8 to 4, there is now a "gap" between procedure roots and procedure tracking that could be closed, so the overall layout could look like:

Section	Start address	Size in elements	Comment
ID and nonce	0	4
Vault root	4	4
Storage commitment	8	4
Code commitment	12	4
Padding	16	12
Num procedures	28	4
Procedures roots	32	1_024	256 procedures max, 4 elements each
Padding	1_056	4
Proc tracking	1_060	256	256 procedures max, 1 element each
Num storage slots	1_316	4
Initial slot info	1_320	1_020	Only initialized on the native account
Storage slot info	2_340	1_020	255 slots max, 8 elements each
Padding	3_360	4_832

Comments:

• As discussed with @Fumuran a while ago, we wanted to specify the end address exclusively, rather than inclusively. So for ID and nonce, 0..4 instead of 0..=3. I did this at first, but the exlusive end address is just the start address in the next row, so I dropped the end address row and instead added the size. I think this table is a bit easier to read and also easier to maintan. For a given row, start address + size should always result in the next row's start address.
• I dropped the equivalent word addresses. We now always access memory on an element basis instead of a word basis, so I think knowing the word address isn't important anymore.
• I switched the order of "initial slot info" and "storage slot info", seems more consistent to have initial slots come before the latest ones.
• Should we rename "Storage slot info" to "Active slot info" or "latest"? Would be good to have a consistent term to refer to it in descriptions such as "The provided pointer must be a valid pointer into the initial or current storage slot section.", where we have recently moved away from the "current" terminology. I suppose "active" would be most consistent.

Context: #2162 (comment)

Tasks:

• If we did everything correctly, this should only require updates to the constants in memory.masm and in memory.rs, plus updating the table in memory.rs to the above.
• If we agree on the above table layout, then we can also update the other tables in memory.rs to the same.</issue_description>

<agent_instructions>make sure to run all tests, and lints, and use makefile to see how to do that</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Close gap in account memory layout #2169

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[mmagician]

@copilot add a changelog entry

[Copilot]

@copilot add a changelog entry

Added changelog entry in bf3a0e3.

[mmagician]

@copilot resolve the merge conflicts

[Copilot]

@copilot resolve the merge conflicts

Merge conflicts resolved in commit b772634. The branch has been successfully rebased on main with the following changes:

1. Resolved conflicts in crates/miden-protocol/asm/kernels/transaction/lib/memory.masm - adapted to new const naming format (without dots)
2. Resolved conflicts in crates/miden-protocol/src/transaction/kernel/procedures.rs - updated kernel procedure hashes for new memory layout
3. Files have been moved from miden-lib to miden-protocol during the rebase

The branch needs to be force-pushed since it was rebased. All tests pass (52 tests in miden-standards, build successful).

[PhilippGackstatter]

I'd go ahead with #2190, since I already reviewed it before and it looks good to me.