fix(ci): nest backport conflict_resolution under experimental input - #3155

…Claim readiness and speed up COSI provisioner failover (#3532)

## What this PR does

Hand-backport of #3034 to `release-1.5`. The `backport` label was
applied at merge time but no backport PR was ever opened, so the change
never reached this branch — found by auditing the branch with
`cmd/backport-audit`, which reported it as `MISSING`.

Every candidate that went missing this way merged before #3155 landed,
when `conflict_resolution` was passed as a top-level input instead of
nested under `experimental`. The action ignored it and fell back to
`fail`, which on a conflicting cherry-pick opens no PR and reports no
failure, so these were dropped with no draft to find and no red check to
notice.

The six original commits are cherry-picked with `-x`, unchanged and in
order. No adaptation was needed: the cherry-pick was clean, and the net
diff is identical to the change on `main`.

### Verification

The two `.diff` files are image patches applied at build time against
upstream `container-object-storage-interface`, so what matters is that
this branch pins the same upstream source. It does — both `release-1.5`
and `main` set `ARG COMMIT_REF=v0.2.2` in
`images/objectstorage/Dockerfile`, and the resulting patch set on this
branch (`91`, `92`, `93`) is byte-identical to `main`'s. Patch `91` was
already present here unchanged, so `92` applies over the same base it
does on `main`.

The branch differs from `main` only in its builder pins (`golang:1.24`
versus `1.26`, unpinned base digests), none of which affect patch
application.

### Screenshots

Not applicable — no UI change.

### Release note

```release-note
fix(objectstorage-controller): converge BucketClaim readiness to the backend Bucket and speed up single-replica COSI provisioner failover
```

…does not crashloop the install gate (#3533)

## What this PR does

Hand-backport of #3138 to `release-1.5`. The `backport` label was
applied at merge time but no backport PR was ever opened, so the change
never reached this branch — found by auditing the branch with
`cmd/backport-audit`, which reported it as `MISSING`. Like the other
items in that set, it merged before #3155 fixed the bot's
`conflict_resolution` input, so the conflicting cherry-pick was dropped
with no draft and no failing check.

Velero binds its metrics/health endpoint (`:8085`) only after loading
plugins and connecting to the API server. Under a heavy parallel
platform install the upstream liveness probe starts checking at
`initialDelaySeconds=10` and kills the container after
`failureThreshold=5`, so velero BackOff-restarts and never escapes the
loop inside the install-gate window. Because `backupstrategy-controller`
hard-depends on velero, this blocks the gate. The fix adds a
`startupProbe`, which holds liveness and readiness off entirely while it
is failing, granting `30 * 10s = 300s` of startup grace and then handing
over to the unchanged upstream liveness for steady-state crash
detection.

### Backport adaptations

This branch vendors velero chart **11.0.0** (appVersion 1.17.0) rather
than `main`'s 12.0.3 (1.18.1), so three things differ from the original.
All are recorded in the commit message as well.

- **The chart version is not bumped.** Only the patch re-application is
added to `update`. The `helm pull` here was previously unpinned, which
would have let `update` float to a chart the patch does not apply to, so
it is pinned to `11.0.0` — the version already vendored. That makes the
new patch step deterministic and leaves the vendored tree
byte-identical.
- **The `test:` target is added.** It exists on `main` but not here, so
without it the shipped regression guard would never run.
- **The image assertions pin this branch's own versions** (velero
`v1.17.0`, `plugin-for-aws` `v1.12.1`, kubevirt plugin `v0.8.0`), and
the `upgrade-crds` rationale is restated for chart 11.0.0, where that
Job still runs a kubectl image — `main`'s comment about the Job running
the velero image natively is true for 12.x only.

The `startupProbe` hunk itself applies to chart 11.0.0's deployment
template unchanged, in the same position inside the `metrics.enabled`
gate.

### Verification

`helm unittest .` passes 5/5 in `packages/system/velero`. The assertions
are mutually corroborating rather than vacuous: the `equal` assertions
prove the `startupProbe` path actually renders, and the same paths are
asserted absent under `velero.metrics.enabled: false`, proving it
follows the same gate as liveness and readiness so disabling metrics can
never leave a `startupProbe` pointed at an unbound port.

### Screenshots

Not applicable — no UI change.

### Release note

```release-note
fix(velero): add a startupProbe so a slow velero server start under heavy parallel install no longer crashloops the container and blocks the install gate
```

The "Cherry-pick triage before a patch" step 1 told the release manager
to inventory backports with `gh pr list --search "is:merged
label:backport"`, annotated "merged but not yet on release-X.Y" --
which that command cannot tell you. It lists every PR ever labelled,
whether or not the change reached the branch. Step 1 now runs
backport-audit, which resolves each label to the line it meant at merge
time and reports what landed, what is waiting on an open backport PR,
what was deliberately dropped and with what reason, and what is missing
outright. Steps 2 and 3 stay: they cover changes that were never
labelled, which the audit structurally cannot see.

Also records the failure mode that makes the audit worth running.
Before #3155, `conflict_resolution` was passed top-level instead of
nested under `experimental`, so the action ignored it and fell back to
`fail`, which on a conflicting cherry-pick opens no PR and reports no
failure. Those backports were dropped with no draft to find and no red
check to notice, so a cluster of MISSING verdicts in one time window is
the signature of that, not of maintainers forgetting.

Pointers added where someone is standing when they need this: the
cherry-pick step of Patch Releases, and the agent-facing release quick
reference, which now says not to call a branch ready to cut on the
strength of a label search.

Assisted-By: Claude <[email protected]>
Signed-off-by: Myasnikov Daniil <[email protected]>

…#3527)

## What this PR does

This adds `cmd/backport-audit`, a maintainer tool that checks, before a
release or an rc is cut, whether everything labelled for backport
actually landed on the release branch. It prints the URLs of the PRs
that did not and exits non-zero, so the cut can gate on it.
`docs/release.md` and `docs/agents/releasing.md` now send the patch-cut
check through it.

The docs it replaces inventoried backports with `gh pr list --search
"is:merged label:kind/backport"`. That lists every PR ever labelled, not
what reached the branch. Answering the real question by hand means
reading the branch history per PR, and that is how backports go missing
quietly.

```console
$ go build ./cmd/backport-audit
$ ./backport-audit release-1.4

=== release-1.4 === 30 candidate PRs: MISSING=5 dropped=4 backported=21

  MISSING -- labelled for this line, no trace of it here (5):
    #2704
      #2704 fix(info): use root-host for Keycloak OIDC issuer URL in tenant kubeconfig
      label=kind/backport author=myasnikovdaniil merged=2026-05-26 -- no backport PR, nothing on branch
```

A `kind/backport` label does not name a branch. `backport.yaml` resolves
the target when the PR merges, so the same label means `release-1.5` on
a PR merged in June and `release-1.6` on one merged in August. The audit
reproduces that rule instead of trusting the label text. The rule
changed once, on 2026-08-03, when 53a7fc4 made cutting an rc freeze
the line and 6ff5b98 pointed the bot at the branch list. Before that
date a line exists from its first stable release, after it from the
moment its `release-X.Y` branch is pushed. The audit estimates that
moment from the earliest `vX.Y.0-rc.N` tagged commit. This is an
estimate, because the commit timestamp is not the branch-push timestamp.
The README has the full reasoning.

Landing is checked per commit, because a commit is what a backport
loses: the bot's conflict drafts stop at the first commit that does not
apply. Every non-empty commit of the original needs its own evidence on
the branch. That is reachability, an `-x` reference, or a commit with
its subject among the branch commits that are not on main. Some but not
all is PARTIAL. A multi-commit original with a merged backport PR and no
commit evidence is UNVERIFIED. Both fail the gate. A maintainer can
confirm a squashed backport with a comment on the merged backport PR
that is exactly `backport-audit: complete`.

Two more sections start from the backport PRs on the branch instead of
from labels. DUPLICATE lists an original with more than one live
backport PR and fails the gate. UNLABELLED lists backports of originals
that are not labelled for this line. It is informational and does not
change the exit code.

Exit code 2 means the audit could not give an answer. That happens when
a `gh` listing reaches its cap, since `gh` truncates silently, or when a
git read that a verdict depends on fails. The label listings are checked
against the lower of `--limit` and 1000, because GitHub search never
returns more than 1000 results.

### Verification

`cmd/backport-audit/main_test.go` covers candidate selection, line
resolution and the evidence rules. `make unit-tests` runs it through a
new `test-backport-audit` target, since `./cmd/...` is not part of
`go-unit-tests`. `hack/release-freeze-contract.bats` pins the audit's
label set equal to the one `backport.yaml` acts on, in both directions.

### Limits

A MISSING verdict is a prompt to check, not proof of absence. A hand
backport that was squashed, reworded and never linked to its original is
invisible to every evidence layer. A label added after merge is read
against the line that was current at merge time, while the bot targets
the line current when the label is added. Such a backport shows as
MISSING on the old line and under UNLABELLED on the new one. The audit
reports that something is missing, never why. `docs/release.md` now
notes that before #3155 the bot left only a "Backport failed" comment on
a conflicting cherry-pick, which is the first thing to check behind a
MISSING.

`make generate` does not apply. This is a standalone `main` package with
no API types, no CRDs and no package `values.yaml`.

### Screenshots

Not a UI change. Sample CLI output is above.

### Downstream repositories

I walked the trigger map in `docs/agents/contributing.md` against the
diff file by file. The diff adds
`cmd/backport-audit/{main.go,main_test.go,README.md}` and changes
`Makefile`, `hack/release-freeze-contract.bats`, `docs/release.md`,
`docs/agents/releasing.md` and one `.gitignore` line for the root
binary.

Nothing in it reaches a downstream repository. No package under
`packages/apps/` or `packages/extra/` is added, renamed or removed, and
no `values.schema.json`, `values.yaml` default or version enum changes,
so the website generator lists and the terraform provider schemas are
untouched. No `ApplicationDefinition` semantics, `release.prefix`,
output Secret or Service name, namespace, platform variant or bundle
changes. The paths that reach ccp and external-apps-example
(`hack/package.mk`, `hack/common-envs.mk`, `hack/update-crd.sh`) are not
touched. The Makefile change adds a `test-backport-audit` target to
`unit-tests` and changes no existing target. No node prerequisite
changes, so talm and the ansible playbooks need nothing. The website
"developer tooling" trigger covers tools contributors use on packages.
This is maintainer release tooling, and its process doc lives in this
repository only.

- [x] No downstream repository is affected by this change
- [ ] [cozystack/website](https://github.com/cozystack/website) -
follow-up:
- [ ]
[cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack)
- follow-up:
- [ ]
[cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack)
- follow-up:
- [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up:
- [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up:
- [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) -
follow-up:
- [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) -
follow-up:
- [ ]
[cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server)
- follow-up:
- [ ]
[cozystack/external-apps-example](https://github.com/cozystack/external-apps-example)
- follow-up:
- [ ] [cozystack/examples](https://github.com/cozystack/examples) -
follow-up:
- [ ] [cozystack/community](https://github.com/cozystack/community) -
follow-up:

### Release note

```release-note
feat(release): add `backport-audit`, a maintainer tool that reports which `kind/backport` / `kind/backport-previous` PRs have not landed on a release branch (missing outright, partially backported, waiting on an open backport PR, or deliberately dropped) and exits non-zero while anything is outstanding, so a patch cut can gate on it
```