fix(postgres): follow-up review remarks from #3954 (KEDA autoscaling) - #4188

[MINOR] the new assertion pins one selector out of four

pattern: kube_pod_labels\{job="kube-state-metrics" matches anywhere in the query string, so one pinned occurrence satisfies it no matter what the other three selectors do. Reverting the pin one line at a time and re-running the suite each time:

unpin _autoscaling.tpl:177 ($joinReplica)  -> GREEN (gap)    [Tests: 66 passed, 66 total]
unpin _autoscaling.tpl:190 ($idleFloor)    -> GREEN (gap)    [Tests: 66 passed, 66 total]
unpin _autoscaling.tpl:203 ($joinCluster)  -> GREEN (gap)    [Tests: 66 passed, 66 total]
unpin _autoscaling.tpl:221 ($frozen)       -> RED (covered)  [Tests: 1 failed, 65 passed, 66 total]

The fix is not vacuously tested: dropping all four pins at once gives Tests: 2 failed, 64 passed. So this is granularity, not a hole. It matters most for $joinReplica at _autoscaling.tpl:177, which carries the read-load signal in both metric modes: unpin only that one in a later edit and CI stays green while the join goes back to matching any exporter's series. One assertion per selector closes it, each pairing the job pin with the label that identifies its site.

[MINOR] the dashboard panels join the same series unpinned

dashboards/db/database-autoscaling.json:56,67,89 joins kube_pod_labels with group_left(label_cnpg_io_cluster) and no job pin, across the read-connections, replica-CPU and replication-lag panels. It ships wherever monitoring does, registered at packages/system/monitoring/dashboards.list:10.

That dashboard is not incidental to this feature: the autoscaling.dryRun field description tells the operator to read the scaling recommendation off "the matching read-load dashboard panel for your metric". Under the exact duplicate-exporter condition this PR defends against, the trigger query is now correct while the panel either double counts or fails outright on the ambiguous match group, so the number the operator sizes maxReplicas from stops agreeing with what KEDA acts on.

Not introduced here, and not in the scope #4187 set, which asked for the query only. No objection to leaving it out of this branch; worth pinning the three expressions in a follow-up, and I will add it to the issue.

[MINOR] a fractional negative floor still renders as 0

The guard reads $min, which is already int .minReplicaCount, and truncation toward zero lets a fractional negative through. On a probe chart wrapping the helper:

$ helm template p ./probe --set-json 'minr=-0.5'
  minReplicaCount: 0
$ helm template p ./probe --set-json 'minr=-1'
Error: execution error at (probe/templates/so.yaml:1:3): cozy-lib.keda.scaledObject: minReplicaCount must be >= 0

So -0.5 produces exactly the scale-to-zero-capable ScaledObject that the type check two blocks above exists to prevent. Latent rather than live: the only production caller passes max(minReplicas, maxSyncReplicas+1, 2), so postgres cannot reach it. Testing the untruncated value closes it, verified on the same probe:

$ sed -i 's/if lt $min 0/if lt (float64 .minReplicaCount) 0.0/' charts/cozy-lib/templates/_keda.tpl
-0.5 -> Error: ... minReplicaCount must be >= 0
-1   -> Error: ... minReplicaCount must be >= 0
0    -> minReplicaCount: 0
2    -> minReplicaCount: 2

[MINOR] the job label does not separate the platform's own second producer

A tenant's guest Kubernetes cluster installs the same monitoring-agents chart and remote-writes into the tenant's store (packages/apps/kubernetes/templates/helmreleases/monitoring-agents.yaml:47 points vmagent at vminsert-shortterm.<tenant>), and that chart relabels job to kube-state-metrics too. What tells the two producers apart is the cluster/tenant external labels set alongside that remote-write, and on(namespace,pod) ignores both. A guest namespace and pod name colliding with the management-side ones therefore still land in the match group, job pin or not.

Contrived to hit, and the failure is fail-safe (an ambiguous match group errors the query rather than mis-scaling), so it does not change my read of the PR. Parity with the alerts is worth having on its own terms. The wording to watch is the commit message's "a duplicate kube_pod_labels series from another exporter cannot multiply the join": within one cluster, yes.

The documentation half is more actionable. A tenant pointing autoscaling.serverAddress at their own vmselect now needs kube_pod_labels carried under that specific job name, and the field description at packages/apps/postgres/values.yaml:148-149 only says the vmselect must hold the series.

[NIT] the annotations case exercises the pass-through branch only

The fixture sets wantAnnotations but never paused, so $annotations comes straight from default (dict) .annotations and the merge at _keda.tpl:123 never runs. That merge is the part worth pinning, since the pause pair is the destination and therefore wins a key collision. #4187 asked for this case specifically as "extra annotations merged under the pause pair". Setting paused on the same fixture and asserting both the caller key and autoscaling.keda.sh/paused-scale-in on one render would cover it.