fix(kafka): keep the pre-delete hook's credentials as long as its Job - #4280

…d gate the class (#4289)

## What this PR does

Fixes #4288, and closes the class behind it and #4276.

`packages/apps/bucket/templates/hooks/cleanup-acme.yaml` passed
`--request-timeout=30s` on all four of its kubectl calls. A non-zero
value there makes kubectl skip its in-cluster credentials: client-go
consults them only while the assembled config still equals the default,
and the flag lands in that config, so every call went to kubectl's
built-in default cluster and was refused.

This package failed more quietly than kafka. Each call is guarded by `||
echo "WARNING: ..."` and the script sets no `-e`, so the hook exited 0
and printed `ACME cleanup complete.`, and `hook-succeeded` then deleted
the Job holding those warnings. The ACME solver objects it exists to
reap were left behind, with the only record removed moments after it was
written. Its own suite matched the rendered command including the flag,
so the broken form was pinned in place.

The gate is the point of the change rather than a bonus. Two packages
carried this, neither was visible in a rendered manifest, and both
passed their unit suites. Nothing stops the next hook from reaching for
the same flag, because it reads as ordinary defensive practice.
`hack/check-hook-request-timeout.bats` fails any non-vendored template
whose kubectl call carries a non-zero `--request-timeout`.

The coarse part is stated in the file rather than left to be discovered:
a template that names `KUBECONFIG` is skipped, because an explicit
kubeconfig is not served by the in-cluster branch and the flag is
harmless there. That is a per-file judgement, not per-command. It is
what lets `apps/kubernetes` keep the flag on two calls that pass their
own kubeconfig and stay green, and it is the first thing to tighten if a
file ever mixes both styles.

Checked in both directions rather than only on the clean tree: the gate
passes as committed, fails if the flag is put back on any bucket call,
fails if it is put back on the kafka call, and leaves the two
`apps/kubernetes` files alone. It also carries a vacuity guard, because
a collapsed glob would otherwise report success for having examined
nothing.

Bounding the work is still available where it belongs: `--timeout` for a
watch, `activeDeadlineSeconds` for the Job, which this hook already had
at 120s.

**Depends on #4280** and is branched off it, so the gate is green here.
#4280 removes the same flag from the kafka hook; merged before it, this
check would be red on `main`.

### Screenshots

Not a UI change.

### Downstream repositories

Walked the trigger map against the diff. A hook's kubectl flags and a
new `hack/*.bats` check; no values key, schema, API, default or naming
contract moves, and nothing under `hack/` is moved or renamed, nor does
any make target change what it does.

- [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
fix(bucket): the ACME cleanup hook now reaches the apiserver instead of reporting success while doing nothing
```


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved ACME cleanup reliability by preventing cleanup commands from
targeting an unavailable local Kubernetes endpoint.
* Improved Kafka uninstall cleanup reliability by ensuring the
pre-delete hook retains access to required credentials throughout
execution.
* Preserved existing execution time limits and warning-based failure
handling for cleanup operations.

* **Tests**
* Added coverage to prevent regressions in Kubernetes cleanup command
configuration and hook resource lifecycle behavior.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

…opic operator is removed (#4456)

Backport of #3938 and #4280 to `release-1.6`, together, because #3938
alone breaks every Kafka deletion (#4276) and #4280 is what fixes that.

Kafka suite on this branch fails the delete step on 2 of the last 3 E2E
runs on the container lane (#4328, #4377), both times with
`UninstallFailed ... KafkaTopic/tenant-test/kafka-test-test-results
termination timeout: context deadline exceeded`. Helm removes the topic
operator together with the release, a KafkaTopic that still carries the
`strimzi.io/topic-operator` finalizer then has nobody to release it, so
uninstall waits out its timeout and leaves the topic behind, which is
what #3793 hits on reinstall. When the operator wins the race the same
delete takes 3s. The pre-delete hook from #3938 deletes the release
topics while the operator is still running, #4280 makes it actually
reach the apiserver and reaps its credentials.

All ten commits cherry-picked clean with `-x`. Kafka on this branch is
still ZooKeeper-based, the hook does not depend on that: it selects
topics by `strimzi.io/cluster=<release>`, the label the 1.6 chart puts
on them.

### Testing

- `make unit-tests` green (kafka helm unit tests and
`hack/kafka-pre-delete-hook.bats` included), POSIX sh sweep clean.
- E2E on this PR runs the kafka suite, which now asserts both release
topics are gone after deletion.

```release-note
fix(kafka): delete release-owned KafkaTopics before removing the Strimzi topic operator
```

A hand backport that carries more than one change names all of them in
one phrase -- "Backport of #3938 and #4280", or "Backport of #4253 to
`release-1.6`, together with #3460" for a dependency pulled along --
and the audit read only the first number after "Backport of". The rest
were linked to nothing. A labelled original in second place then read
as MISSING while its backport PR was still open, instead of pending,
and once that PR merged it counted as landed only if the branch history
happened to prove it.

Read the whole reference list the phrase carries, and the together-with
form this repository writes. A list counts in full only when it visibly
ends: at the end of the line or the sentence, or where a "to
release-X.Y" clause names the target line, with the line name a whole
word: release-1.6-fixes, release-1.6.1 and release-1.6.fixes are not
lines, so punctuation after the name ends it only when a space or the
end of the text follows. One that runs on into anything else --
"Backport of #10, #20 is not included", or "#10, #20 to follow in a
separate PR" -- may be saying something about its later items, so only
its first reference, the one the phrase names directly, is kept. The issue a backport fixes, or a CI run it cites further on in
the body, is never taken for an original.

A reference qualified with another repository is now skipped instead of
read as a local number. That also tightens the old first-number rule,
which accepted any owner/repo prefix: "Backport of other/repo#20" linked
local #20, so a merged backport of something unrelated could turn that
PR's MISSING verdict into backported. Only a bare #N or one qualified
with the repository the backport PR itself lives in, compared without
regard to case, is an original.

Over every PR on release-1.4, release-1.5 and release-1.6 this changes
the links of exactly four: #4456 and #4421 each gain #4280, #4377 gains
#4231 and #4328 gains #3460. No verdict moves today, since none of the
added originals carries a backport label.

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

The audit started from labels and dropped every backport PR whose
original was not a candidate for the branch. On release-1.6 that hid
nine hand backports of unlabelled main PRs (#4431 to #4435, #4437,
#4438, #4456 and #4475), and it had no way to notice two open backport
PRs for the same originals: #4421 sat open next to #4456 for #3938 and
#4280, and nothing reported it.

Read the PRs on the branch from the side of the originals they claim as
well, and report two more sections per branch.

UNLABELLED lists each original claimed by backport PRs on the branch
that is not a candidate for it, with every backport PR claiming it and
its state, and says whether they backported it, only claim it with a PR
still open, or were all closed. It never moves the exit code: the gate
answers whether everything labelled landed, and an unlabelled backport
can only add to a branch, never leave a labelled change off it.

DUPLICATE lists each original claimed by two open backport PRs, or by
an open one after another already merged, labelled or not. Both make
the audit exit 1. One of the PRs is redundant, or the open one is the
rest of a split backport; either way someone has to decide before the
cut, and no verdict can say so, since a verdict settles on the first
merged backport or reports the first open one as pending. A closed PR
next to an open one is how a conflicting bot backport gets redone by
hand and is not flagged.

The titles of originals that no listing carries come from one GraphQL
request for the whole run. A failed lookup costs the titles and nothing
else: the URL is derived locally and the exit code is already settled.

--json now emits an object per branch holding candidates, unlabelled
and duplicates arrays, in place of the bare array of verdicts.

On release-1.6 today this lists 13 unlabelled originals, the nine above
among them, and three duplicates that are open right now: the bot's
conflict drafts for #3936, #4254 and #4292 were left open next to their
hand backports, and #4254 and #4292 each also have a fork PR open next
to its reopening from a branch in this repository. #4421 is closed and
shows up only as a closed claim on #4280.

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