fix(conformance): reset the pg_dump archive between cases - #211

## The bug

`pg_dump` writes a partitioned parent's primary key as

```sql
ALTER TABLE ONLY public.readings ADD CONSTRAINT readings_pkey PRIMARY KEY (taken_on, id);
```

`ONLY` means the index reaches the partitions that exist **at the moment
it runs** and no others. In `pg_dump`'s own output order the key
precedes every `CREATE TABLE ... PARTITION OF`, so they inherit it and
the migration is correct.

Reorder the statements and it silently isn't. Grouping a fix set by
object kind — every table created before any constraint is added — is a
reasonable way to apply a migration, and SupaForge's `orderStatements`
does exactly that (`CREATE_TABLE` phase 40 before `ALTER_TABLE` phase
50). The partitions are then created before the key is added, never
receive it, and the migration reports success having dropped it.

**This reached 3.0.0-rc.10.** Every partitioned table with a primary key
diffed by that release, on a machine with `pg_dump`, loses its partition
keys when applied by a consumer that reorders. It surfaced as a
SupaForge e2e failure whose fingerprint showed the partitions missing
`readings_2025_pkey` / `readings_2026_pkey`, their indexes, and the
`inh` attach links.

Introduced by `4e9c912` ("render DDL with pg_dump when it is
available"), which put `PgDumpRenderer::tableDDL()` first in
`getCreateStatement` for **every** table. rc.9 was immune because the
built-in renderer emits the key inline.

## The fix

Partition metadata is read before `pg_dump` is tried, so partitioned
tables use the built-in renderer and get the key inside `CREATE TABLE`,
where the statement order cannot matter.

The real fault is DDL whose correctness depends on the order it happens
to be written in. This is also what the README already claimed —
"Partitions always use the built-in renderer" — which stopped being true
when `pg_dump` rendering began taking precedence.

## Why the suite missed it

The corpus **does** cover partitioned tables with primary keys
(`obj_partitioned_range`, `obj_partition_index`,
`hard_part_index_propagated`), and those cases passed throughout.

The conformance runner applies DBDiff's statements in DBDiff's own order
— the one order in which this bug is invisible. Nothing asserted that
the emitted DDL survives being reordered.

So that is what the new test does.
`PartitionedTableRendererPostgresTest` has two cases, both verified to
fail without this change:

- the parent's key is inline and the DDL contains no `ALTER TABLE ONLY`
- the statements are replayed with every `CREATE TABLE` moved first, and
each partition must still have its primary key — without the fix this
fails with `readings_2025 lost its primary key`

The second encodes the property rather than the symptom, and is the one
that would have caught the original regression.

I also considered and **disproved** two other explanations before
finding this: that the stale `pg_dump` archive cache (#211) was hiding
it, and that single-transaction application in the runner was masking
it. Both were tested; neither holds.

## Cost

One corpus case: `hard_part_expr_key`, an expression partition key that
`pg_dump` reproduced and the built-in renderer does not. It was already
in `known-failures.json`, so the baseline is unchanged and the suite
reports no new failures. Measured back to back, twice each way, to be
sure of the delta.

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

The README's figure and the reason for the exception are updated.

## Test plan

- [x] New test fails without the fix (both cases), passes with it
- [x] Verified the fix is targeted, not a blanket disable: an ordinary
table still renders via `pg_dump`, a partitioned parent does not
- [x] Full conformance suite, both renderer modes: `Failed (no diff):
0`, **zero new failures** (304 with `pg_dump`, 291 built-in)
- [x] 782 unit, 68 Postgres, 16 SQLite pass
- [x] Corpus delta measured back to back in one session rather than from
separate runs, after an initial single measurement proved to be an
artifact of leftover scratch databases

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