refactor: unify contract compilation pipeline via bb aztec_process

[benesjan]

When working on another PR of mine I realized that we are having a problem and that is that we have 2 paths by which contracts get compiled:

1. one is via aztec-packages bootstrap,
2. another is via aztec compile

This started to become problematic as our contract compilation pipeline was getting more complicated:

1. nargo compile,
2. transpile,
3. strip prefixes,
4. and with that PR also inject aztec version

This meant that the duplication started to have real cost. In this PR I clean this up a bit by moving the prefix stripping into the bb aztec_process command. This results that the compilation pipeline is simply:

1. nargo compile,
2. bb aztec_process

Given that it's just 2 commands it is fine to have it be duplicated between bootstrap.sh and aztec compile. Once this is merged I will try to refactor #22550 such that the version is also injected only in bb aztec_process.

AI Summary

• Moved __aztec_nr_internals__ prefix stripping into bb aztec_process (C++), which already handles transpilation and VK generation
• Simplified the bootstrap compile function to just call nargo compile + bb aztec_process, removing ~50 lines of manual VK generation shell code
• Removed the separate stripInternalPrefixes() TypeScript function from the CLI path
• Deleted the now-unused strip_aztec_nr_prefix.sh script
• Updated protocol-fuzzer scripts and docs to reflect the unified pipeline

Both compilation paths (bootstrap and aztec compile) now go through bb aztec_process for all post-nargo processing, eliminating the duplication.

[Thunkar]

This is a lot of bootstrap code removed. Have we lost per-vk CI caches? will this impact bootstrap performance?

[benesjan]

No meaningful perf loss — likely a slight improvement.

The old per-VK cache was actually redundant with the outer contract cache:

Old flow — two caches, both keyed by $contract_hash:

• Outer contract-$contract_hash.tar.gz: compiled+transpiled JSON without VKs
• Inner vk-$contract_hash-$funchash.tar.gz: one per private function

The per-VK key included $contract_hash as a namespace, so it could only hit when $contract_hash matched a prior run — i.e., exactly the same scenarios where the outer cache also hit. Cross-contract_hash VK reuse was never possible. The per-VK cache was only necessary because the outer cache didn't contain VKs.

New flow — one cache, same key:

• contract-$contract_hash.tar.gz now contains the fully processed JSON including VKs (produced in one shot by bb aztec_process).

Perf comparison:

• Cold build (contract_hash changed): equivalent work in both. New path uses C++ threads with nested parallelism in generate_vks_for_functions instead of GNU parallel shelling out per function — likely a bit faster with less overhead.
• Warm build: strictly faster — one tarball download instead of 1 + N.
• Bonus: there's a new local VK cache at ~/.bb/$BB_VERSION/vk_cache/<bytecode_hash>.vk keyed on pure bytecode hash (no contract_hash namespace), giving dev-machine reuse across contracts that the old flow didn't have.

The only theoretical regression would be if the old per-VK cache were keyed on just $funchash (enabling cross-contract_hash reuse) — but it wasn't, so nothing's lost.

[mverzilli]

LGTM, though please note I currently have very little context on this code

[AztecBot]

❌ Failed to cherry-pick to v4-next due to conflicts. (🤖) View backport run.