Fragile conditional logic for operator_tag in global-ci.yml

## Description
The conditional logic for operator_tag uses a mix of startsWith() checks and exact equality checks, creating fragile conditions that could fail unexpectedly.

## Location
.github/workflows/global-ci.yml

## Details

### Current approach uses mixed patterns:
- Lines 204, 210, 216 (minikube): Uses `startsWith(inputs.operator_tag, 'v0.7')` and `startsWith(inputs.operator_tag, 'v0.8')`
- Line 216: Uses `startsWith(inputs.operator_tag, 'latest')`
- Lines 244, 255, 266 (install): Uses `startsWith(inputs.operator_tag, 'v0.7')` and `startsWith(inputs.operator_tag, 'v0.8')`
- Lines 266, 412: Uses exact match `inputs.operator_tag == 'latest'`

### Inconsistencies:
1. Line 216 uses `startsWith(inputs.operator_tag, 'latest')` for minikube
2. Line 266 uses `inputs.operator_tag == 'latest'` for install
3. Line 412 uses `inputs.operator_tag == 'latest'` for install (UI tests)

## Problems

### Problem 1: Inconsistent latest check
Some use `startsWith('latest')` while others use `== 'latest'`.

### Problem 2: No catch-all fallback
What happens if someone passes:
- `v0.9.0` (new version not handled)
- `latest-foo` (matches startsWith but not ==)
- `v0.7.0-rc1` (matches startsWith correctly)
- Empty string or unexpected value

## Impact
- Tag like `latest-custom` would match the startsWith check for minikube but not the == check for install
- New operator versions (v0.9, v1.0, etc.) would have no matching condition
- Workflow would fail or use wrong action branch
- Hard to debug why certain tags don't work

## Recommendation

### Option 1: Add explicit fallback
Add a final conditional for any unmatched tags:
```yaml
- name: start minikube
uses: konveyor/tackle2-operator/.github/actions/start-minikube@main
if: |
!startsWith(inputs.operator_tag, 'v0.7') &&
!startsWith(inputs.operator_tag, 'v0.8')
```

### Option 2: Standardize on one pattern
Use consistent logic:
- `startsWith('v0.7')` for v0.7.x versions
- `startsWith('v0.8')` for v0.8.x versions
- Everything else defaults to @main

### Option 3: Make it explicit
```yaml
if: |
inputs.operator_tag == 'latest' ||
inputs.operator_tag == 'main' ||
(!startsWith(inputs.operator_tag, 'v0.7') &&
!startsWith(inputs.operator_tag, 'v0.8'))
```

## Related Files
- .github/workflows/global-ci.yml:204 (startsWith for v0.7)
- .github/workflows/global-ci.yml:210 (startsWith for v0.8)
- .github/workflows/global-ci.yml:216 (startsWith for latest)
- .github/workflows/global-ci.yml:244 (startsWith for v0.7)
- .github/workflows/global-ci.yml:255 (startsWith for v0.8)
- .github/workflows/global-ci.yml:266 (== for latest)
- .github/workflows/global-ci.yml:412 (== for latest)

Read the conditional blocks in .github/workflows/global-ci.yml around lines 204-266 and 412, comparing the minikube, install, and UI-test handling of operator_tag. Decide the intended behavior for latest, versioned tags, and unmatched values, then verify that each listed input follows one consistent branch and that the workflow remains valid.

Written by the indexing model from the issue text.