fix: shift right overflow in ACIR with unknown var now returns zero

[asterite]

Description

Problem

Resolves #7412

Summary

The explanation of the bug is here: #7412 (comment)

This is one way to solve this. I wonder if there's a better one (less ops).

Additional Context

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Memory'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 31996c6	Previous: ef51d8a	Ratio
rollup-base-private	582.03 MB	441.61 MB	1.32
rollup-block-root	3500 MB	1420 MB	2.46

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 31996c6	Previous: ef51d8a	Ratio
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_blob	61 s	50 s	1.22

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[github-actions]

Changes to circuit sizes

Generated at commit: 9ffb0c8478b2b79e2e334748759ab7cbd99ea3b7, compared to commit: ebaff44cae9d9dc9d930fe2ccf4a1ce85bcd8d3c

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
bit_shifts_runtime	+7 ❌	+2.46%	+7 ❌	+0.18%
u128_type	+3 ❌	+2.11%	+3 ❌	+0.07%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
bit_shifts_runtime	291 (+7)	+2.46%	3,952 (+7)	+0.18%
u128_type	145 (+3)	+2.11%	4,609 (+3)	+0.07%

[jfecher]

Looks like Rust panics when this happens. Are we sure we want to return 0 in acir then instead of changing brillig to also halt?

[asterite]

In a chat with @TomAFrench on Slack he said that ideally it's zero. But it's a good opportunity to revisit this as I also tend to prefer matching Rust's behavior.

[jfecher]

@TomAFrench can you elaborate here (or on the linked issue) why zero is preferable to erroring?

[TomAFrench]

I suggested this as currently the program

fn main(x: u8) -> pub u8 {
    x >> 9
}

returns 0 when given an input of 1 so we have precedent. (we should create an error for this case if we're wanting to reject larger shifts)

I was also thinking of these lines in the sha256 impl where when we're bitshifting by a value which is only known at runtime and need to add a guard to avoid this error case.

[jfecher]

The regressions seem fairly small