TL;DR

WaitForDelete could either return success before a resource was actually deleted
(the TestStatusWaitForDelete flake, #32261) or, with the naive fix, hang until
--timeout on an already-gone resource (#32214). Both come from the delete path
trusting a resource's transient Unknown status. This reworks the path to start the
watcher first and, once it has synced, confirm any still-Unknown target with a
metadata.name-filtered LIST — an authoritative check instead of a heuristic.

Background — what actually goes wrong on main

The delete-path observer skips Unknown resources:

if rs.Status == status.UnknownStatus && desired == status.NotFoundStatus {
    continue
}

During informer sync every target is briefly Unknown, so they are all skipped, the
aggregated status of the (now empty) set is NotFound, and the watch is cancelled —
WaitForDelete returns success before any deletion is confirmed. That is the #32261
flake.

The obvious fix — stop skipping Unknown — breaks the other direction: the kstatus
watcher only reports NotFound from an observed delete event, and never emits one
for an object that was already absent from its initial LIST. Such a target stays
Unknown forever and the wait hangs to the timeout (the #32214 regression, which is
why the earlier attempt was reverted).

So Unknown on the delete path is ambiguous: it means "already gone" or "still
being deleted", and the watcher alone cannot disambiguate the already-gone case.

Change

• waitForDelete starts the StatusWatcher first, then drives a small
  deleteReconciler. When the watcher emits its Sync event, any target still
  Unknown is confirmed with a metadata.name-filtered LIST against the same
  dynamic client and REST mapper the watch uses. An empty result means the object is
  gone; the target is marked confirmed-gone, separately from the collector, and the
  wait can complete. The Unknown-as-deleted heuristic is removed entirely.
• No new RBAC. A filtered LIST is authorized as the list verb the watcher
  already requires — unlike a point GET, which needs the separate get verb.
  Identities scoped to list/watch but not get (common for controllers) keep
  working.
• Failure isolation. Each still-Unknown target is confirmed by its own checker
  goroutine, under a bounded concurrency limit, retrying on its own backoff. A slow or
  stuck LIST for one target does not block another target's check, and one target's
  server Retry-After never defers another target's retry. When the watcher gives a
  target a definitive status, that target's in-flight check is cancelled. Retries are
  bounded only by the overall wait context — no arbitrary per-request timeout is
  imposed, so a slow aggregated API is not prematurely failed.
• Backpressure-aware retry. Retriable errors use an explicit allowlist
  (throttling, API/server timeouts, service-unavailable, and recognized transport
  failures — connection refused/reset, lost HTTP/2 connection, probable EOF, net-level
  timeout). The per-target backoff honors a server-requested Retry-After, capped so a
  single large hint cannot consume the wait budget.
• Faithful error reporting. A context error (cancel/deadline) takes precedence over
  the watch-ended-before-confirmation error and is returned discoverable via
  errors.Is (diagnostics for still-present resources may accompany it, but the
  watch-ended sentinel never does). A deletion that was fully confirmed is reported as
  success even if the deadline fires as the last confirmation lands.

The observer performs no API I/O; every cluster read happens in the reconciler, off
the event path.

Tests

pkg/kube/statuswait_test.go adds deterministic coverage:

• fake StatusWatchers for the full path: a target absent from the initial LIST is
  confirmed gone by the reconcile (not left hanging); a transient error is retried; an
  outage longer than the retry window still resolves; the watch closing with an
  unconfirmed target returns the sentinel and not a context error; context cancel
  during a blocking LIST returns context.Canceled alone; a parent deadline propagates
  as DeadlineExceeded; one always-failing target does not starve a second; a target
  whose LIST is stuck in flight does not block a second target from being confirmed
  concurrently; and one target's long Retry-After does not delay another's retry.
• direct deleteReconciler state-machine unit tests for the invariants that a fake
  cannot pin down deterministically: a still-Unknown target never signals completion
  (anti-flake); a live-confirmed-gone target is not resurrected by a stale late
  Current; a fully confirmed deletion reports success even under an expired context.
• table-driven tests for the retriable-error allowlist, the Retry-After extraction,
  and the per-target retry wait (including the cap), plus the resourceGone LIST
  classification and its defensive field-selector check.

go test -race -count=100 -run 'TestStatusWaitForDelete|TestDeleteReconciler' ./pkg/kube/ is stable.

Manual verification (local, not CI)

The dynamic fake ignores FieldSelector, so the LIST path was also verified on a
real API server (a disposable kind cluster), not in CI. A matrix confirmed
gone-detection for namespaced built-ins, a cluster-scoped resource, a CRD, an absent
object, and a same-named decoy — and, crucially, that an identity with list/watch
but not get (kubectl auth can-i reports list=yes, watch=yes, get=no) completes
WaitForDelete, where a point GET would be Forbidden. These runs are local evidence;
no kind/integration job is wired into CI in this PR.

Review requested

Two points I'd like maintainer input on before this goes further:

1. Ownership. This confirms deletion Helm-side, via a filtered LIST after the
   watcher syncs. The alternative is to have the upstream watcher
   (fluxcd/cli-utils) emit an initial NotFound for targets absent from its first
   LIST, fixing this class of races at the source and letting Helm drop the reconcile
   entirely. The Helm-side fallback is self-contained and needs no upstream change, but
   I'd welcome a call on whether this belongs here or should be driven upstream.
2. Fail-closed policy. Non-allowlisted errors (a 500 InternalError, NoMatch
   from a removed CRD, malformed-request errors) deliberately fail the wait closed
   rather than retry. This is the conservative choice; if maintainers would prefer to
   also retry transient 500s, that's a one-line allowlist change — I left it out on
   purpose and would rather it be an explicit decision.

Issue

Fixes #32261