…pping the pod range (#4432)

Backport of #3750 to `release-1.6`.

Sandbox Talos config and platform install on this branch still both use
`10.244.0.0/16`, so kube-ovn and cilium allocate from one range and
cilium refuses pod sandboxes with `IP ... is already in use`. It hit
`mariadb-2-backup-roundtrip` on the E2E run of #4328 here.

Cherry-picked clean with `-x`.

### Testing

- `make unit-tests` green, POSIX sh sweep clean.
- Real check is E2E on this PR.

```release-note
NONE
```

…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]>