Camel Quarkus choice execution bug

### Bug description

### Describe the bug

It looks like fix (https://issues.apache.org/jira/browse/CAMEL-21958) for Camel 4.12.0 introduced in Camel Quarkus 3.24.0 / Quarkus 3.24.x (tested with 3.24.0 until 3.24.5) introduces a breaking change (the requirement to use .end().endChoice() instead of .endChoice() only in specific situations) and a bug, where parts of the route after the final .end() of a choice() are not accessible any more!

This causes complex routes with nested choices to fail.

### Expected behavior

Expected behaviour would be to have the routes not breaking from Quarkus 3.23.4 to 3.24.5+.
May be, accepting the breaking change regarding .end().endChoice() would be acceptable, but the described bug is not.

### Actual behavior

The route parts after the final .end() (or .end().endChoice() alternatively) of the outer choice() are not accessed - see example code.

### How to Reproduce?

```
from("direct:test-route")
.setBody(constant("Test"))
.setHeader("test", constant("B"))
.setHeader("test2", constant("X"))
.log(LoggingLevel.INFO, "Processing choice level 0 before test=${header.test}")
.log(LoggingLevel.INFO, "Processing choice level 0 before test=${header.test2}")
.choice()
.when(header("test").isEqualTo("A"))
.log(LoggingLevel.INFO, "Processing choice level 1 when test=${header.test}")
.when(header("test").isEqualTo("B"))
.log(LoggingLevel.INFO, "Processing choice level 1 when test=${header.test}")
.choice()
.when(header("test2").isEqualTo("A"))
.log(LoggingLevel.INFO, "Processing choice level 2 when test2=${header.test2}")
.when(header("test2").isEqualTo("B"))
.log(LoggingLevel.INFO, "Processing choice level 2 when test2=${header.test2}")
.otherwise()
.log(LoggingLevel.INFO, "Processing choice level 2 otherwise test2=${header.test2}")
//TODO .endChoice() replaced with .end().endChoice() for Quarkus 3.24.0 and Camel 4.12.0
.end().endChoice()
.log(LoggingLevel.INFO, "Processing choice level 1 after .end().endChoice() test=${header.test}")
.otherwise()
.log(LoggingLevel.INFO, "Processing choice level 1 otherwise test=${header.test}")
.choice()
.when(header("test2").isEqualTo("C"))
.log(LoggingLevel.INFO, "Processing choice level 2 when test2=${header.test2}")
.when(header("test2").isEqualTo("D"))
.log(LoggingLevel.INFO, "Processing choice level 2 when test2=${header.test2}")
.otherwise()
.log(LoggingLevel.INFO, "Processing choice level 2 otherwise test2=${header.test2}")
.endChoice()
.log(LoggingLevel.INFO, "Processing choice level 1 after .endChoice() test=${header.test}")
.end()
// alternatively .end().endChoice()
//FIXME never logged or accessed since Quarkus 3.24.x!
.log(LoggingLevel.INFO, "Processing choice level 0 after .end() test=${header.test}")
.log(LoggingLevel.INFO, "Processing choice level 0 after .end() test2=${header.test2}")
;
```

When executing the route above the last 2 log statements are not executed since Quarkus 3.24.0, but would be with Quarkus 3.23.4. Changing the outer choice() related end() statement to end().endChoice() has the same result (and there is no build error, compared to the nested choice() otherwise() part, maked with TODO above).

### Output of `uname -a` or `ver`

MacBookPro.xxx.xxx 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:26 PDT 2025; root:xnu-11417.121.6~2/RELEASE_X86_64 x86_64

### Output of `java -version`

GraalVM CE OpenJDK 21 [21.0.2+13.1]

### Quarkus version or git rev

Since 3.24.0 until 3.24.5 minimum

### Build tool (ie. output of `mvnw --version` or `gradlew --version`)

Eclipse IDE embebedded 3.9.9/3.9.900.20250220-2013

### Additional information

I expect this to be a Camel issue (related to https://issues.apache.org/jira/browse/CAMEL-21958), but as Quarkus manages the Camel Quarkus implementation, I opened it up here to get it tracked within Quarkus.

Start by running the nested choice route from the issue against Quarkus/Camel Quarkus 3.23.4 and 3.24.x, including both end() variants, and compare which log statements execute. Review the behavior introduced by CAMEL-21958; done means the route remains compatible or the final outer-choice log statements execute correctly on affected versions.

Written by the indexing model from the issue text.