fix(cloud-backups): alert on uncovered base paths, not absent months

[logicflakes]

Follow-up to #14. That PR's missing-target guard is firing as a false positive on customer prod, and will keep doing so on every run until this lands.

- error = 1 of 4 target(s) produced no backup because the repository was reported absent:
          rearm-artifacts/downloadable-artifacts-2026-08
- msg   = backup_targets_missing_from_registry
- time  = 2026-08-15T08:26:16Z

#14 merged at 00:52 UTC that day; this alert is the merged code.

Why it fires

Under rolling months the tool does no discovery. It fabricates <base>-<current month> and <base>-<previous month> from the clock and attempts each, learning of absence by failing to back the target up.

Meanwhile a monthly repository is never created explicitly -- registries create one implicitly on first push, and both writers derive the same name from the UTC clock at push time (rebom-backend ociService.getMonthlyRepositoryName, rearm-core ArtifactService.getMonthlyRepositoryName). So a base path that receives no artifacts in a month has no repository for that month at all.

SBOMs land constantly, so rebom-artifacts-2026-08 always exists. Downloadable artifacts only land when a release publishes one -- none had been published in August, so that repo had never been created. #14's guard assumed a current-month target must exist: true for the first path, false for the second. It would page every run until the month's first downloadable, then again every new month, for any path without guaranteed monthly traffic.

The fix

Alert per base path, not per target: did this base path produce any backup at all?

One month absent is indistinguishable from a quiet month. A base path producing nothing is unambiguous, and is exactly what a renamed, deleted or mistyped path looks like. Under explicit paths a base path expands to one target, so the strict behaviour there is preserved by construction rather than by a special case. SkipIsExpected and the whole current-vs-previous month distinction are deleted.

Why not an existence check

Considered seriously and rejected as unreachable, not merely undesirable. Distinguishing "never created" from "deleted" needs state the credential envelope does not contain:

• The registry cannot enumerate repositories without catalogue scope.
• The destination cannot be read back under the write-only credential that storage.Provider's contract deliberately preserves.
• Conditional writes do leak existence using write permission alone (S3 If-None-Match: * -> 412, Azure -> 409 BlobAlreadyExists) -- but the probe that answers "absent" succeeds, leaving an undeleteable 0-byte object at the real backup key. It destroys the answer it returns. If-Match: * is worse: it overwrites a live backup. A marker-key variant fails identically.

Worth recording for whoever revisits that decision: on Azure the write-only ideal in the Provider comment is not achievable with RBAC anyway -- there is no built-in write-only blob role, so the SP must hold Storage Blob Data Contributor, which already grants read. A probe would be zero-elevation on that deployment; the constraint is real only for S3.

Residual gap, stated deliberately

A current-month repo deleted while the previous month survives will not alert -- because with the available information that is indistinguishable from a quiet month. Closing it needs either s3:ListBucket / blob read, or an explicit per-path requireMonthly flag in the chart. Both remain open; neither is needed for the reported failure.

Verification

Rig reproduces the production shape exactly (rebom present for both months, downloadable present only for the previous month):

build	ERROR lines to operator
merged code (b5e60ae)	1 -- reproduces the customer alert verbatim
this branch	0
base path absent in both months	1, naming the path

go build / go vet / go test -race ./... clean, gofmt clean, added lines pure ASCII.

Note on the last check: my first attempt to prove the alert still fires used curl -X DELETE against registry:2, which returns 405 because delete is disabled by default -- the repo never went away, so that run's "0 errors" was correct but meaningless. Re-verified with a base path that genuinely has no repositories.

🤖 Generated with Claude Code