The operator was repeatedly logging "Secret already exists, updating"
and "Following standardized STS workflow, secret created successfully"
even when the secret content hadn't changed. This was happening because
the CloudStorage controller calls STSStandardizedFlow() on every
reconciliation, which always attempted to create the secret first,
then caught the AlreadyExists error and performed an update.

Changed the approach to:
- First check if the secret exists
- Compare existing data with desired data
- Only update when there are actual differences
- Skip updates and avoid logging when content is identical
- Changed CloudStorage controller to use Debug level and more accurate
  message when STS secret is available (not necessarily created)

This eliminates unnecessary API calls to the Kubernetes cluster and
reduces noise in the operator logs.

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

Co-Authored-By: Claude <noreply@anthropic.com>

- Add Conditions field to CloudStorageStatus for better observability
- Implement exponential backoff by returning errors on bucket operations
- Controller-runtime automatically handles retries (5ms to 1000s max)
- Add condition constants for type-safe reason strings
- Create mock bucket client for improved testing
- Add comprehensive tests for backoff behavior and conditions

Key improvements:
- Standard Kubernetes pattern using built-in workqueue backoff
- Self-healing: continues retrying with increasing delays
- Better observability through status conditions
- Per-item backoff: each CloudStorage CR gets independent retry timing

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

Co-Authored-By: Claude <noreply@anthropic.com>