BB panics when proving acir program regression_5045

[sirasistant]

Panic here: https://github.com/AztecProtocol/aztec-packages/actions/runs/10993886364/job/30521864534?pr=8663

  +barretenberg-acir-tests-bb *failed* | Testing regression_5045... bb command is: prove
  +barretenberg-acir-tests-bb *failed* | building circuit...
  +barretenberg-acir-tests-bb *failed* | gates: 1206
  +barretenberg-acir-tests-bb *failed* | circuit is recursive friendly: 0
  +barretenberg-acir-tests-bb *failed* | using cached bn254 crs of size 1677722 at "/root/.bb-crs/bn254_g1.dat"
  +barretenberg-acir-tests-bb *failed* | Initializing BN254 prover CRS from memory with num points = 3277
  +barretenberg-acir-tests-bb *failed* | computing proving key...
  +barretenberg-acir-tests-bb *failed* | bb: /usr/src/barretenberg/src/barretenberg/stdlib_circuit_builders/circuit_builder_base.hpp:102: FF bb::CircuitBuilderBase<bb::field<bb::Bn254FrParams>>::get_variable(const uint32_t) const [FF_ = bb::field<bb::Bn254FrParams>]: Assertion `(variables.size() > index)' failed.
  +barretenberg-acir-tests-bb *failed* | Aborted (core dumped)
  +barretenberg-acir-tests-bb *failed* | FAILED
  +barretenberg-acir-tests-bb *failed* | ERROR Earthfile:30:4
  +barretenberg-acir-tests-bb *failed* |       The command
  +barretenberg-acir-tests-bb *failed* |           RUN FLOW=prove_then_verify ./run_acir_tests.sh
  +barretenberg-acir-tests-bb *failed* |       did not complete successfully. Exit code 1

Skipping the test to unblock the noir sync for now

[maramihali]

I have investigated this issue as part of another task. It stems from the fact that one of the points that is in the input to the create_ecc_add_constraint, specifically input_1 has input_1_x and input_1_y constants and input1_infinite not a constant. This gets passed to create_grumpkin_point which instantiates a cycle_group element that is non-constant and so the incoming code in bberg will do strange things because we never expect this to happen (either all three fields are not constant or they are). More explicitly, here input1_point will be non-const but because x and y are constants their witness index will be garbage values that eventually (in trace sorting ) are used to index a vector which the point where the crash happen. The 442th element of block.wires[1] (contain variable indices) is a garbage value.
If the point is made a constant (so input1_infinite set to constant somehow) case the test would pass.