This change addresses the flaky ReconciliationTest failure where the sensor
fails to detect resource deletions that occurred during sensor downtime.

ROX-29382 represents a recurring flaky test failure in `ReconciliationTest` where
the sensor fails to detect resource deletions that occurred during sensor downtime.
The test intermittently reports 0 deletions when ≥1 deletions are expected,
specifically affecting `*central.SensorEvent_Secret` and `*central.SensorEvent_NetworkPolicy` resources.

**Root Cause**: Timing/race condition in sensor reconciliation logic where the test
checks reconciliation statistics before the sensor completes full resource state
comparison and deletion detection.

- Extract reconciliation waiting logic into dedicated @Retry annotated function
- Wait for actual deletion detection, not just reconciliation completion status
- Add enhanced logging for debugging timing issues
- Use StackRox @Retry annotation with 30 attempts and 5-second delays
- Improve error messages with expected vs actual values

The race condition occurred because the test checked `reconciliationDone=true`
but didn't ensure all deletions had been detected yet. This implementation
waits for both reconciliation completion AND non-empty deletion counts.

<details>
<summary>Technical Analysis</summary>

```groovy
def "Verify the Sensor reconciles after being restarted"() {
    1. Create test resources (Secret, NetworkPolicy, Deployment, Pod)
    2. Scale sensor deployment to 0 (sensor goes offline)
    3. Delete test resources while sensor is down
    4. Scale sensor deployment to 1 (sensor restarts)
    5. Wait for reconciliation completion
    6. Verify reconciliation stats show ≥1 deletions detected
}
```

```groovy
// From ROX-29382 failure
EXPECTED_MIN_DELETIONS_BY_KEY = [
    "*central.SensorEvent_Secret": 1,           // Expected ≥1, Got 0
    "*central.SensorEvent_NetworkPolicy": 1,    // Expected ≥1, Got 0
    "*central.SensorEvent_Pod": 1,              // Expected ≥1, Got 0
    "*central.SensorEvent_Deployment": 1,       // Expected ≥1, Got 0
    "*central.SensorEvent_Namespace": 1,        // Expected ≥1, Got 0
]
```

The reconciliation process happens in this order:
1. **Reconciliation starts**: Sensor sends deduper sync complete event
2. **Pipeline.Reconcile()** is called - processes all resource differences
3. **reconciliationMap.Close()** is called - populates deletion counts
4. **reconciliationDone becomes true**

The race condition occurs due to asynchronous nature of connection handling
and potential delays between when reconciliationMap.Close() is called and
when the API endpoint reflects the changes.

</details>

<details>
<summary>Historical Context</summary>

1. **2022-2023**: "Overly aggressive reconciliation" - sensor detected MORE deletions than expected
2. **2025**: "Under-detection reconciliation" - sensor detected FEWER deletions than expected

This pattern shift suggests the reconciliation mechanism has changed behavior over time.

- Only fails on GKE compatibility tests
- Skipped on OpenShift (`@IgnoreIf({ Env.mustGetOrchestratorType() == OrchestratorTypes.OPENSHIFT })`)
- Environment-specific timing differences

</details>

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Tomasz Janiszewski <tomek@redhat.com>