Rebase, renumber and re-measure before #7 can merge #10

Blocking #7 (component atomization), from an independent review on
2026-09-28. The extraction itself is faithful; the evidence around it is not.

1. The pinned component version does not exist. --branch v1.0.0 on a
   repository with no tags. Tracked in The version the recipe pins, v1.0.0, does not exist unit-postgresql#2.
2. The branch is CONFLICTING against main, and the equivalence
   measurement predates the current tree. Since the merge base, main gained
   merges touching Makefile and conf.d/main, including a root.patched/pre
   hook on the same target where fab applies the units. All four builds behind
   the "0 attributable differences" claim were made against that older tree.
   The merged tree has never been built.
3. The changelog revision has been overtaken and fails the gate on rebase,
   verified by running the gate's own entry_version / version_increased
   against current main.

Two method findings, which outlive this pull request:

• The measurement is blind inside /var/lib/postgresql/**, where only paths are
  compared and never the nature of the difference — and that is where the
  account tables live. There is no real difference today (established by
  diffing the conf scripts against common), but the reported measurement is
  not what establishes it.
• The measurement is not reproducible: the capture lives in a scratch
  directory on the build host and the comparison step is committed nowhere,
  although decision 0010 step 3 instructs re-running it for every future
  component. Being fixed separately.

Also: the three green checks never build the composed layer —
appliance / build-and-boot boots the published layer, which on a recipe
change is the code before the change. Keel-Linux/.github#11.

Closes when the branch is rebased, the changelog renumbered, the component
pinned to something that exists, and the four builds re-run with the committed
harness and their output quoted in the pull request.

Specific to this repository's component

Two build steps are dead on Debian 13, and the test fixture invents the file
that would make them work. unit-postgresql/conf:32 and :35 match
#password_encryption = on and shared_buffers = 32; PostgreSQL 17's
postgresql.conf.sample has #password_encryption = scram-sha-256 at line 97
and #shared_buffers = 128MB at line 129. tests/conf.bats writes a fixture
containing the old strings, claims in a comment that it is what
pg_createcluster leaves behind, and asserts the transformation. Two of eleven
assertions pass against a file the build never produces, with 100 percent
coverage reported on that basis.

The image is not wrong — the seds were equally dead in common/conf/pgsql, and
PostgreSQL 17 defaults to scram-sha-256. The suite certifying dead lines as
working is the defect. Build the fixture from the installed sample; then either
delete the seds, which changes the image and needs its own changelog entry, or
assert they are no-ops and say why. The listen_addresses tests in the same
file are the standard to meet.

Before LAPP composes this component: the component defaults to
postgres/postgres and the only removal lives in this recipe's conf.d/main.
By decision 0013 LAPP composes the unit onto apache-php, not onto this
recipe, so LAPP inherits the well-known password unless its conf.d repeats
the removal — the copy-paste the split exists to prevent. Documented in
conf-vars, enforced nowhere.