fix: stale status writes at dependency gate points cause conflict errors

[digiserg]

Summary

Multiple r.Status().Update() calls at lines 473-484 and 514-526 in axonopsserver_controller.go operate on a potentially stale server object. The CR is not re-fetched before writing status after multiple Create/Update operations. This causes conflict errors and requeue loops.

Detailed Requirements

The Kubernetes API server uses resource versions for optimistic concurrency. When the reconciler performs multiple Create/Update operations on child resources, the server object's resource version becomes stale. Subsequent r.Status().Update() calls fail with 409 Conflict errors, triggering unnecessary requeue cycles.

The fix must add r.Get(ctx, req.NamespacedName, server) before each r.Status().Update() call at the dependency gate points. This follows the controller-runtime best practice documented in AGENTS.md: "Re-fetch before updates."

Location

• internal/controller/axonopsserver_controller.go:473-484
• internal/controller/axonopsserver_controller.go:514-526

Acceptance Criteria

1. CR is re-fetched via r.Get() before every r.Status().Update() call at dependency gate points
2. No conflict errors during normal reconciliation of a complete AxonOpsServer CR
3. Unit test verifies status updates succeed after multiple resource modifications in a single reconcile
4. All status update paths in the Reconcile method follow the re-fetch pattern consistently

Testing Requirements

• Unit test: TestReconcile_StatusUpdateAfterMultipleResourceCreations — create server with all components, verify no conflict errors
• Unit test: Inject a fake client that returns Conflict on stale writes, verify the re-fetch resolves it
• Review all other r.Status().Update() calls in the file for the same pattern

Documentation Requirements

• Add code comment at each re-fetch site explaining why it is necessary

Dependencies

• None

Priority

BLOCKING — causes reconciliation loops and delayed convergence