chore(noir-projects): include constants.nr in protocol-circuits compile cache key

[AztecBot]

Why

Most recent merge-train/barretenberg CI run failed on a single test out of ~8000:

FAILED: nargo execute --program-dir noir-projects/noir-protocol-circuits/crates/private-kernel-init
  The value passed for parameter `private_call.vk.key` does not match the specified type:
  Type Array { length: 139, typ: Field } is expected to have length 139 but value Vec(...) has length 127

Run: https://github.com/AztecProtocol/aztec-packages/actions/runs/25474428940
Log: http://ci.aztec-labs.com/1778123397019978

The branch's source code is internally consistent at length 127:

• constants.nr:616 — MEGA_VK_LENGTH_IN_FIELDS: u32 = 127
• verification_key.nr:24-26 — ChonkVerificationKey = VerificationKey<MEGA_VK_LENGTH_IN_FIELDS>
• private-kernel-init/Prover.toml — exactly 127 vk.key field entries
• C++ to_field_elements() — 3 (metadata) + 31 × 4 (commitments) = 127
• MEGA_VK_LENGTH_IN_FIELDS has been 127 throughout git history — git log -G "MEGA_VK_LENGTH_IN_FIELDS" shows no commit at 139.

A freshly-built nargo (release, noir submodule at d52888d57c = nightly-2026-05-05, the version pinned by this branch) compiles private_kernel_init and produces target/private_kernel_init.json with vk.key.type.length = 127. nargo execute then prints Circuit witness successfully solved. The failure does not reproduce locally.

Diagnosis

For nargo to type-check the input as Array { length: 139 } while source agrees on 127, the target/<name>.json artifact in CI must have come from a cache populated when the compile produced 139.

compile() in noir-projects/noir-protocol-circuits/bootstrap.sh keys cached artifacts as:

local hash=$(hash_str "$NOIR_HASH-$program_hash" \
  $(cache_content_hash "^noir-projects/noir-protocol-circuits/bootstrap.sh"))

Locally I verified that toggling MEGA_VK_LENGTH_IN_FIELDS between 127 and 139 does change program_hash (87b6db9679f8ef13 vs b2aa470d6ac30748), so in principle the formula should bust the cache when the constant changes. In practice this CI failure proves it isn't sufficient — most likely a 64-bit program_hash collision across noir versions or a pipeline path where the hash is taken before full monomorphization.

The same hazard is exactly what barretenberg/cpp/CLAUDE.md documents in #23014 (the commit on top of this branch when CI ran), but framed around ChonkProofData/proof length. ChonkVerificationKey length sits on the same axis.

Fix

Add crates/types/src/constants.nr to the cache_content_hash regex inside compile(). That file holds all the proof/VK length globals that propagate into ABI array sizes (CHONK_PROOF_LENGTH, MEGA_VK_LENGTH_IN_FIELDS, etc.). Including it makes any change to those constants deterministically bust cached circuit-*.tar.gz artifacts, independent of nargo check --show-program-hash. It also busts the currently-poisoned cache entry, letting the next CI run recompile cleanly.

The pre-existing comment about deliberately excluding circuits_hash (so unrelated test/comment edits don't force global rebuilds) is preserved — this change only adds the one constants file.

Verification

• bash -n noir-projects/noir-protocol-circuits/bootstrap.sh — syntax OK.
• After the change, nargo execute --program-dir noir-projects/noir-protocol-circuits/crates/<crate> prints Circuit witness successfully solved for private-kernel-init, private-kernel-inner, private-kernel-reset, rollup-tx-base-private.
• Cache-key formula change is additive: no behavior change for any compile that currently succeeds; no new rebuild triggers beyond constants.nr edits.

Detailed analysis: https://gist.github.com/AztecBot/bcfd1fa804e1df126df0d6d9d5e4a59f

ClaudeBox log: https://claudebox.work/s/dcab673e828476ab?run=1

[AztecBot]

Automatically closing this stale claudebox draft PR (no updates for 5+ days). Re-open if still needed.