Make JdbcExampleTest robust to reruns and command registration race

[jbonofre]

What

Makes org.apache.karaf.itests.examples.JdbcExampleTest robust so it no longer fails intermittently on CI (observed on the test (windows-latest) job).

Why it was failing

The test hard-coded the booking id (1) and asserted on a shared literal flight code (AF520):

1. The commands (booking:add/list/get/remove) are registered asynchronously as independent SCR components. On the slower Windows runner, the freshly-created shell session hit a registration race and booking:remove threw CommandNotFoundException.
2. That tripped the whole-method @Retry in KarafTestSupport, which re-runs test(). But the example stores bookings in an AUTO_INCREMENT H2 table that persists across runs of the same Karaf instance, so the rerun's booking:add got id 2 while id 1's AF520 row lingered.
3. booking:remove 1 + assertContainsNot("AF520") then failed deterministically — which is the assertion seen in the CI log.

The fix

• Use a unique flight code per run ("AF" + System.currentTimeMillis()) so leftover rows from a previous/retried run cannot disturb the assertions.
• Resolve the actual auto-incremented id from the booking:list output instead of assuming 1, and remove exactly that row.

With these changes the test is isolated from leftover data and @Retry can genuinely recover from the transient command-registration race.

Test-only change.