docs: say what the diff actually covers - #210

## Summary

`PgDumpRenderer` caches one `pg_dump` archive per `host|port|database`
for the life of the process, and its own `reset()` exists for "a process
that reconnects". The conformance runner is exactly that: every case
drops and recreates `pgconf_before`, `pgconf_after` and `pgconf_test`
under those same three names, so from the **second case onward the
renderer answered from the first case's dump**.

The effect was to make PostgreSQL's own tooling look far worse than the
hand-written renderer it is meant to exceed:

| PostgreSQL 16, 90-case renderer corpus | before | after |
|---|---|---|
| built-in | 68 / 90 | 68 / 90 |
| with `pg_dump` | 16 / 90 | **82 / 90** |

The built-in row not moving is the control — the change only touches the
`pg_dump` path.

## Nothing was being hidden

Worth stating, because the alternative would have been serious. Across
the full suite, in both renderer modes, there are **no failures outside
the baseline and no case that passed before stops passing**:

| renderer | passed | new failures | baselined but passing |
|---|---|---|---|
| built-in | 291 | 0 | 3 |
| with `pg_dump` | 305 | 0 | 17 |

The stale archive only ever *lost* cases, which is why it survived
unnoticed: the suite stayed green because every case it broke was
already recorded as a known failure. `known-failures.json` therefore
needs no additions.

## Why the baseline stays where it is

It stays pinned to the built-in renderer rather than dropping to the 8
hard cases that fail with `pg_dump`. That is the figure every
environment can meet — pruning to the `pg_dump` result would report 14
new failures on any machine without `pg_dump` installed, which includes
most contributors.

The trade is that a run which *does* have `pg_dump` now reports 17 cases
as baselined-but-passing. The runner already treats that as
informational rather than fatal, for the same reason it does
version-specific differences: *"a case that fails on one version can
legitimately pass on another. Failing the run for that would mean no
single baseline could ever satisfy the whole matrix."* Renderer
availability is the same class of variation.

If the noise is unwelcome, the alternatives are a per-renderer baseline
or pinning the conformance job to one renderer — both more machinery
than the problem currently justifies.

## README

The fidelity table was measured before this bug and is corrected here,
with the server version stated because the numbers move with it: the
built-in renderer reproduces 67 on PostgreSQL 18, where `LIKE ...
INCLUDING ALL` copies the named NOT NULL constraints that release
introduced, and `pg_dump` older than the server is not used at all so
those runs score as built-in.

## Test plan

- [x] 90-case corpus re-measured both renderer modes on PostgreSQL 16
and 18
- [x] PostgreSQL 18 scores 67 in *both* modes, confirming the renderer
correctly declines when older than the server (client 17.11 vs server
18) rather than silently misrendering
- [x] Full suite both modes: `Failed (no diff): 0`, zero new failures,
baseline unchanged at 37
- [x] Checked no other harness shares the bug — `phpunit.xml` pins
`DBDIFF_PG_DUMP_RENDERER=off`, and `PgDumpRendererPostgresTest` already
calls `reset()` and enables the renderer only for itself

Stacked on #210 only by adjacency in the README; that PR does not touch
the table.

🤖 Generated with [Claude Code](https://claude.com/claude-code)