Prepare postgres-barman to be public

[malpou]

Closes #1 (the code half of it).

The image was built generic on purpose -- "nothing in it knows which database it will hold" -- and that held up, so the audit is short. Only the prose named the internal consumers.

What changed

• README -- the mermaid diagram's three consumer nodes collapse to "your databases"; "One image, every MetsaApp database" is reworded; the Kamal example's oresult user/db, s3://o-result-backups/api, the o-result-production server name and the Hetzner fsn1 endpoint become obvious placeholders.
• Dockerfile -- the header comment named the same three consumers. Comment-only: the digest, the build assertions and the venv install are byte-identical, so the published image does not change and no consumer re-pins.
• LICENSE -- MIT.
• SECURITY.md -- private advisories, no SLA we won't keep, honest that most of the surface is upstream Postgres and Barman.

Everything else stays. The CloudNativePG rejection, the PG_VERSION/initdb trap and the digest-pinning rationale are generic, and are more useful in public than in private.

No history rewrite. There are no credentials in any commit, and force-pushing would break clones and invalidate the 18-20260712 tag pinned in production.

Checks

grep -riE 'o-result|oresult|metsa api|zitadel|fsn1|your-objectstorage' over the tree is clean. I could not run docker build locally (no Docker in this WSL distro) -- the PR build here is the real check.

Still to do, outside this PR

• Branch protection on main
• Secret scanning + push protection on -- the durable guard that keeps "no credentials" true
• GHCR package visibility -- a public repo does not make its package public. Miss this and the repo is a Dockerfile nobody can pull the result of.
• Coordinate with MetsaApp/pgctl#7 -- these go public together or not at all. pgctl builds FROM this image; a public pgctl pointing at a private base is worse than useless.