chore: regenerate deepcopy and CRD manifests (#239)

* Log per-metric PU candidates on scale events

In dual CPU scaling mode, the "updated processing units via google cloud
api" log only reported before/after PU values, so operators could not
tell which metric (highPriority or total) drove a scale event after the
fact. The Kubernetes "Updated" Event had the same gap.

Refactor calcDesiredProcessingUnits to return a scaleDecision struct
that bundles the chosen PU with the per-metric candidates
(DesiredByHighPriority, DesiredByTotal). The Reconcile loop now logs
both candidates alongside the configured metric type and current CPU
utilizations on the three scale-related sites:

- V(1) "processing units need to be changed"
- Info "updated processing units via google cloud api"
- Kubernetes "Updated" Event

Readers can identify the driving metric by comparing the after value
against DesiredByHighPriority and DesiredByTotal — no separate "driver"
field is materialized.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Regenerate deepcopy and CRD manifests

Two prior PRs added api/v1beta1 changes without running the
controller-gen targets, leaving local drift that surfaces every time a
contributor runs `make manifests generate`:

- #227 (scale down time restriction) added ScaleConfig.ScaledownNotAllowedTimes
  but did not regenerate DeepCopyInto. Without the generated copy, a
  deep-copied ScaleConfig shares the underlying slice with the original;
  any future code that mutates the field on a copy would corrupt the
  informer cache.
- #237 (CPU metric observability) expanded the godoc for
  currentHighPriorityCPUUtilization and currentTotalCPUUtilization but
  did not regenerate the CRD YAML, so `kubectl explain` still shows the
  older descriptions.

This commit is purely the output of `make manifests generate` — no
hand edits.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: tkuchiki

api/v1beta1/zz_generated.deepcopy.go

@@ -477,8 +477,16 @@ spec:
                 - Both
                 type: string
               currentHighPriorityCPUUtilization:
-                description: Current average CPU utilization for high priority task,
-                  represented as a percentage
+                description: |-
+                  Current average CPU utilization for high priority task, represented as a percentage.
+                  In dual CPU scaling mode (both highPriority and total configured), this value is
+                  fetched concurrently with currentTotalCPUUtilization. Because Cloud Monitoring
+                  ingests the underlying metrics (utilization_by_priority and utilization) independently,
+                  the two fields may briefly reflect different alignment windows and the relation
+                  currentTotalCPUUtilization >= currentHighPriorityCPUUtilization is not guaranteed
+                  on every sync. The autoscaling decision uses both values independently and takes
+                  the larger required processing units, so the transient inconsistency does not cause
+                  over-scaling down.
                 type: integer
               currentProcessingUnits:
                 description: Current number of processing-units in the Spanner instance
@@ -487,6 +495,7 @@ spec:
                 description: |-
                   Current total CPU utilization (all priorities), represented as a percentage.
                   This field is populated only when spec.scaleConfig.targetCPUUtilization.total is specified.
+                  See the note on currentHighPriorityCPUUtilization for the consistency caveat in dual mode.
                 type: integer
               currentlyActiveSchedules:
                 description: List of all the schedules which are currently active