refactor: replace deprecated Result.Requeue in controller reconcilers

[christian-heusel]

What / Why

controller-runtime deprecates reconcile.Result.Requeue in favor of RequeueAfter / returning an error. The dependency bump in #1306 moves the controller to controller-runtime v0.24.1, where staticcheck flags every Result{Requeue: true} usage as SA1019:

This setting is deprecated as it causes confusion and there is no good
reason to use it. When waiting for an external event to happen, either the
duration until it is supposed to happen or an appropriate poll interval
should be used, rather than an interval emitted by a ratelimiter whose
purpose it is to control retry on error.
Deprecated: Use `RequeueAfter` instead.

This PR removes all 16 usages in the controller reconcilers. The change is valid on the current v0.19.1 too, so it can land independently of #1306.

This is intentionally opened as a draft to agree on the approach before polishing. The mechanical part is settled; the open question is the logging tradeoff below.

Commit layout

1. chore: bump Go dependencies in controller — a temporary cherry-pick of the controller dependency bump from chore: Bump golang dependencies in backend & controller #1306, included here only so this PR's CI exercises controller-runtime v0.24.1, i.e. a version where Result.Requeue is actually deprecated and staticcheck flags it. It is identical to the commit in chore: Bump golang dependencies in backend & controller #1306 and will drop out on rebase once chore: Bump golang dependencies in backend & controller #1306 merges into notebooks-v2.
2. refactor: replace deprecated Result.Requeue … — the actual change under review.

Please review the second commit; the first is scaffolding.

Approach

The reconciler used Requeue: true in two distinct situations, handled differently:

Situation	Count	Old	New	Rationale
IsConflict(err) retry after an update	14	return Result{Requeue: true}, nil	return Result{}, err	A conflict is an error; returning it lets the workqueue rate-limiter handle retry-on-error — exactly what the deprecation note says that limiter is for. Preserves the identical rate-limited/backoff behavior.
Stale cache (owned ServiceAccount not yet cached)	2	return Result{Requeue: true}, nil	return Result{}, nil	We already Owns(&ServiceAccount{}), so the owned-object watch will requeue us — the existing code comments already say so. No explicit requeue needed.

mergeReconcileResult() no longer inspects the deprecated .Requeue field and merges purely on RequeueAfter; its unit test was updated to match.

Options considered

Option	Requeue timing	Logging	Notes
A. return the error (this PR)	immediate, rate-limited backoff — identical to Requeue: true	conflict now logged at error level by controller-runtime	Matches the deprecation's stated rationale; smallest behavioral change to timing.
B. RequeueAfter: <small const>	fixed delay, no exponential backoff	stays quiet (returns nil)	Changes retry cadence; needs a somewhat arbitrary constant.
C. //nolint:staticcheck	unchanged	unchanged	Keeps the deprecated API; just silences the linter.

🗣️ Discussion points

1. Logging noise (main one). With option A, benign optimistic-concurrency conflicts — previously logged only at V(2) and returned as nil — now surface via controller-runtime's "Reconciler error" at error level (and bump the error metric). Is that acceptable, or do we prefer option B (RequeueAfter) to keep conflicts quiet at the cost of changing the retry cadence?
2. Stale-cache sites. Is relying solely on the Owns(&ServiceAccount{}) watch to requeue acceptable, or would you rather keep an explicit short RequeueAfter as a safety net?
3. Scope. Should this also convert k8s.io/apimachinery/pkg/util/httpstream → k8s.io/streaming/pkg/httpstream (the other SA1019 the bump surfaces), or keep that as a separate PR?

related: #1306

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign andyatmiami for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• workspaces/controller/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment