chore: update Noir to v1.0.0-beta.22 (v5-next) (#23870)

## Summary

Bumps the `noir/noir-repo` submodule on `v5-next` to the official
**noir-lang/noir `v1.0.0-beta.22`** release (`c57152f`), replacing the
off-mainline `temp-serialization-tag` commit (`f1a4575`, "Fixes") that
v5-next was pinned to. This is so v5 is built from a proper noir release
rather than a nightly/temp tag.

## Changes

- **`noir/noir-repo`** → `c57152f91260ecdb9faad4efc20abb14b6d2ece7`
(`v1.0.0-beta.22`).
- **`avm-transpiler/Cargo.lock`** → noir crates `1.0.0-beta.21` →
`1.0.0-beta.22` (adds `msgpack_tagged`, `serde_bytes`, `bs58`,
`tinyvec`; bumps `darling` 0.23, `serde_with` 3.20). This matches the
lockfile delta the automated nightly noir-sync produces.
- **`noir-projects/aztec-nr`** — replace the now-deprecated
`BoundedVec::from_parts_unchecked` with `BoundedVec::from_parts` in
`note_getter.nr` and `utils/array/subbvec.nr`. beta.22 deprecates
`from_parts_unchecked` (`from_parts` no longer needs the extra zeroing
loop), and `aztec-nr`'s CI step runs `nargo check --deny-warnings`, so
the deprecation is a hard failure without this. Same fix the team's
`cb/bump-noir-with-from-parts-fix` branch applied.

## Verification (local)

- Built `nargo` from the beta.22 submodule (`noirc
1.0.0-beta.22+c57152f`).
- `cargo build` of `avm-transpiler` against beta.22: **passes** (no
source changes needed beyond the lockfile).
- `noir-protocol-circuits` `crates/types` + representative binaries
(`parity-root`, `private-kernel-init`, `private-kernel-tail`,
`rollup-block-root`, `rollup-root`) compile clean.
- Full `noir-contracts` workspace `nargo compile --silence-warnings`:
**passes**.
- `aztec-nr` `nargo check --deny-warnings`: **fails before** the
from_parts fix (on the two files above), **passes after**.

## Remaining knock-on — `yarn-project/yarn.lock` (needs CI/maintainer
regen)

beta.22 bumps the published noir JS package versions
(`@aztec/noir-acvm_js`, `noirc_abi`, `noir_js`, `types`, `noir_codegen`)
`1.0.0-beta.21` → `1.0.0-beta.22`. Because `yarn install` runs
`--immutable` in CI, `yarn-project/yarn.lock` must be refreshed:

- 6 `1.0.0-beta.21` → `1.0.0-beta.22` version strings, plus
- the regenerated `@aztec/noir-noir_js@file:` resolution `hash=` and
`checksum:` (content-derived).

This is exactly the lockfile refresh the nightly noir-sync performs
automatically (see the precedent in `7683ee71a58`). I could **not**
regenerate it in this sandbox: producing the `noir_js` `file:` checksum
requires building the noir JS/wasm packages (`noir/bootstrap.sh`), and
the wasm toolchain (`wasm-bindgen`/`wasm-opt`) install is
network-blocked here (crates.io index unreachable). To finish locally:

```bash
cd noir && ./bootstrap.sh           # builds noir/packages/* at beta.22
cd ../yarn-project && yarn install  # refreshes yarn.lock
```

Then commit the resulting `yarn-project/yarn.lock`.

Tracking label `private-port-next` added per the v5 sync request.

---
*Created by
[claudebox](https://claudebox.work/v2/sessions/60a7ac646b5b7cbd) ·
group: `slackbot`*

Author: ludamad

avm-transpiler/Cargo.lock

@@ -258,9 +258,7 @@ where
         };
     }
 
-    // We can use `from_parts_unchecked` instead of `from_parts` because we know that `confirmed_notes_bvec_storage`
-    // contains all zeroes past `hinted_notes.len()` due to how it was initialized.
-    BoundedVec::from_parts_unchecked(confirmed_notes_bvec_storage, hinted_notes.len())
+    BoundedVec::from_parts(confirmed_notes_bvec_storage, hinted_notes.len())
 }
 
 pub unconstrained fn view_note<Note>(owner: Option<AztecAddress>, storage_slot: Field) -> HintedNote<Note>

noir-projects/aztec-nr/aztec/src/note/note_getter.nr

@@ -19,11 +19,9 @@ pub fn subbvec<T, let SrcMaxLen: u32, let DstMaxLen: u32>(
     bvec: BoundedVec<T, SrcMaxLen>,
     offset: u32,
 ) -> BoundedVec<T, DstMaxLen> {
-    // from_parts_unchecked does not verify that the elements past len are zeroed, but that is not an issue in our case
-    // because we're constructing the new storage array as a subarray of the original one (which should have zeroed
-    // storage past len), guaranteeing correctness. This is because `subarray` does not allow extending arrays past
-    // their original length.
-    BoundedVec::from_parts_unchecked(array::subarray(bvec.storage(), offset), bvec.len() - offset)
+    // The new storage array is a subarray of the original one (which has zeroed storage past len), so elements past
+    // the new len remain zeroed: `subarray` does not allow extending arrays past their original length.
+    BoundedVec::from_parts(array::subarray(bvec.storage(), offset), bvec.len() - offset)
 }
 
 mod test {