The generated changelog is a good inventory but carries no operator-facing
layer: no required-actions section, no runnable pre-upgrade checks, and the
SeaweedFS 4.31 rename left as three isolated fix bullets that never say what
to do about it. Every generated bullet is preserved; this adds to them.

Widen the base to v1.5.2. v1.5.3 was tagged but its release was never
published and its changelog PR was closed unmerged, so docs/changelogs/
v1.5.3.md exists on no ref and a v1.5.3 base leaves #3212 (persistent
EFI/TPM state) and #3194 (filer postgres2 connection pool) documented
nowhere at all. Coverage is now 82/82 commits in range.

Correct three claims. The slot 45 divergence is a skip rather than an
ordering problem: v1.5.4 is the first 1.5.x stamped targetVersion 46, and
run-migrations.sh loops seq CURRENT (TARGET - 1), so a cluster at 46 runs
46..53 on the way to 1.6 and never executes 1.6's own slot 45. Its chart-side
half was missing too, and it is not redundant -- a fresh v1.5.4 install is
stamped 46 having never run any slot, so only the chart can reach it. The
S3 checksum bullet named a barman-cloud plugin path that does not exist on
this branch.

The audit re-run warning names v1.6.0, not earlier releases. The script does
not exist at v1.5.2; v1.5.4 is the first 1.5.x to carry it and carries the
fail-closed version. v1.6.0 shipped the copy that silenced every kubectl
failure, so a clean table from it is not evidence.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

…udit note (#3910)

Adds the changelog for `v1.5.4`, and corrects one still-live instruction
in v1.6.0's.

The generated changelog is a good inventory and every one of its bullets
is kept. What it had no layer for is the operator: no required-actions
section, no runnable pre-upgrade checks, and the SeaweedFS 4.31 rename
left as three isolated fix bullets that never say what to do about it.
That is what is added on top, in the shape v1.6.0's changelog uses.

Base widened to `v1.5.2`. v1.5.3 was tagged but its release was never
published and its changelog PR was closed unmerged, so
`docs/changelogs/v1.5.3.md` exists on no ref and a v1.5.3 base leaves
#3212 (persistent EFI/TPM state) and #3194 (filer postgres2 connection
pool) documented nowhere at all. Coverage is 82/82 commits in range.

Three claims corrected. The slot 45 divergence is a skip rather than an
ordering problem: v1.5.4 is the first 1.5.x release stamped
`targetVersion: 46`, and `run-migrations.sh` loops `seq CURRENT (TARGET
- 1)`, so a cluster that reaches 46 runs slots 46 through 53 on the way
to 1.6 and never executes 1.6's own slot 45. Its chart-side half was
missing too and is not redundant, because a fresh v1.5.4 install is
stamped 46 having never run any slot, so only the chart can reach that
population. And the S3 checksum bullet named a barman-cloud plugin path
that does not exist on `release-1.5`.

The audit re-run warning names v1.6.0 rather than an earlier release,
because the script does not exist at v1.5.2 at all. v1.5.4 is the first
1.5.x release to carry it, and it carries the fail-closed version.

The second commit edits `docs/changelogs/v1.6.0.md`, which is deliberate
rather than an accident of scope. Published changelogs are historical
records and are normally left alone, but v1.6.0's upgrade notes still
tell operators to run `hack/seaweedfs-naming-audit.sh`, and the copy
that shipped in v1.6.0 silences every `kubectl` call with `2>/dev/null`.
A timeout or an RBAC denial therefore prints an empty all-clean table
indistinguishable from a genuinely clean fleet, and that output gates a
runbook step that deletes PVCs. Verified per tag: v1.6.0 carries 11
blanket redirections and no `run_kubectl` wrapper, while v1.6.1, v1.6.2
and v1.5.4 carry 4 and 18, the fail-closed shape from #3436 and its
backport #3474.