test: fix flaky additionalFinalizer in TriggerReconcilerOnAllEventIT (#3434)

* test: fix flaky additionalFinalizer in TriggerReconcilerOnAllEventIT

The phase-1 await could pass prematurely: right after create() the resource
already has exactly [ADDITIONAL_FINALIZER], before the operator adds its own
FINALIZER. This snapshotted a stale event count, so the phase-2
isEqualTo(eventCount + 1) assertion against a monotonic counter would overshoot
and time out.

Wait for the operator to add its own finalizer before deleting, so phase 1
reflects the completed add/mark-for-deletion/remove cycle and the baseline is
deterministic.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>

* format

Signed-off-by: Attila Mészáros <a_meszaros@apple.com>

---------

Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: csviri

operator-framework/src/test/java/io/javaoperatorsdk/operator/baseapi/triggerallevent/eventing/TriggerReconcilerOnAllEventIT.java

@@ -130,6 +130,17 @@ void additionalFinalizer() {
 
     extension.create(res);
 
+    // Wait until the operator has added its own finalizer before deleting. Right after create the
+    // resource already has exactly [ADDITIONAL_FINALIZER], so without this the assertion below
+    // could
+    // pass prematurely (before the add/mark-for-deletion/remove cycle), snapshotting a stale event
+    // count and making the phase-2 `eventCount + 1` assertion flaky.
+    await()
+        .untilAsserted(
+            () ->
+                assertThat(getResource().getMetadata().getFinalizers())
+                    .containsExactlyInAnyOrder(ADDITIONAL_FINALIZER, FINALIZER));
+
     extension.delete(getResource());
 
     await()