Populate DisaggregatedSet .status from owned LWS objects (#933)

* Populate DisaggregatedSet .status from owned LWS objects

The DisaggregatedSet controller reconciled LWS objects but never wrote
.status, leaving it permanently empty ({}). This adds:

- status.observedGeneration, mirroring LeaderWorkerSetStatus.
- status.roleStatuses[]: replicas/readyReplicas/updatedReplicas per role,
  aggregated across all slices and revisions of that role's LWS objects.
- status.conditions: Available when every role's replicas are fully
  ready and updated to the current revision, Progressing otherwise.

* Preserve LastTransitionTime when a condition's Status does not change

setDisaggregatedSetCondition reset LastTransitionTime on every write,
including when only ObservedGeneration advanced but the condition's
Status stayed the same. Per the metav1.Condition contract,
LastTransitionTime must only change on an actual Status transition;
otherwise every reconcile after a spec change looks like a fresh
transition to clients.

Reported by @Copilot in review.

* Filter LWS listing by controller owner UID; document role-removal contract

Address two review points from @yankay on #868:

- LeaderWorkerSetManager.List (and GetRevisionRolesList, which uses it)
  matched LWS by name/role labels only. An LWS that happens to carry the
  same labels but isn't actually owned by this DisaggregatedSet -
  hand-crafted, or left over from a same-named DisaggregatedSet that was
  deleted and recreated - could inflate the status replica counts. List
  now takes the DisaggregatedSet object and additionally filters results
  by metav1.IsControlledBy, matching every LWS this manager creates
  (which already carries a controller owner reference). Existing test
  fixtures that build LWS via a bare OwnerReference (missing
  Controller: true) are updated to match what the real Create() path
  sets, plus a new "unowned" fixture in TestManagerListSliceBucketing
  pins the exclusion directly.

- updateStatus only visits current spec.roles, so a role removed from
  spec.roles drops out of status.roleStatuses immediately, even though
  its old LWS is not itself deleted by this reconcile (nothing currently
  scales down or removes a removed role's leftover LWS - a pre-existing
  lifecycle gap, out of scope here). Documented this as the explicit
  contract on RoleStatuses and updateStatus, and added
  TestStatusDropsRemovedRoleEvenWhileItsLWSStillDrains to pin it.

* Split off Available/Progressing into a follow-up PR

Per @yankay's review, this PR now covers only the foundational status
reporting: observedGeneration and per-role roleStatuses aggregated from
owned LWS objects. The Available/Progressing condition model (desired
targets, slices, zero-replica behavior, condition interaction, failure
semantics) moves to a follow-up PR for focused review, carried over
from this branch's prior state with its tests and the LastTransitionTime
fix already applied.

Reverts the DisaggregatedSetConditionType/Available/Progressing
constants and the condition-setting half of updateStatus; restores the
original Conditions doc comment (including the "Degraded" bullet, since
no condition type is implemented by this PR). Regenerated CRD manifests
and API reference docs to match.