GeezerVison

**Builds on #265.** Merge that first; this PR's diff includes #265's
commit until then.

**The bug** (present in rc.25 and earlier)
- The data diff's streaming merge walks both tables in primary-key order
and pairs rows up.
- The database sorted text keys one way, and PHP compared them another:
- **Numeric-looking text** (`'10'`, `'9'`): the server sorts as text
(`'10' < '9'`), but the merge compared them as numbers.
- **Linguistic collations** (PostgreSQL `en_US` / ICU, MySQL's default
`utf8mb4_0900_ai_ci`): the server sorts `'a' < 'B'`, but the merge
compared bytes (`'B' < 'a'`).
- When the two orders disagree at a difference, the merge falls out of
step and reports rows **both sides have** as a `DELETE` and an `INSERT`.
- Replaying that leaves the row itself intact. But an `ON DELETE
CASCADE` child goes with it, delete triggers fire, and the migration is
wrong either way.

Reproduced on PostgreSQL 18 (glibc `en_US.utf8`) and MySQL 8.0. For
example, a target missing only `'a'`, `'apple'` and `'10'` produced:
```sql
DELETE FROM `t` WHERE `code` = '9';
DELETE FROM `t` WHERE `code` = 'B';
INSERT INTO `t` (`code`,`v`) VALUES('10','5');
INSERT INTO `t` (`code`,`v`) VALUES('9','4');
INSERT INTO `t` (`code`,`v`) VALUES('B','2');
INSERT INTO `t` (`code`,`v`) VALUES('a','1');
INSERT INTO `t` (`code`,`v`) VALUES('apple','6');
```
With this fix, the same diff is just the three `INSERT`s.

PostgreSQL images on Alpine sort `en_US` as bytes, so they hide the
problem; Debian images and Supabase don't.

**The fix:** each key column is ordered by the server and compared by
the merge the same way, chosen from its type in the catalog.

| Key type | Server `ORDER BY` | Merge compares |
|---|---|---|
| Number | native (index used) | as numbers |
| uuid (PostgreSQL) | native (index used), which is already hex order |
bytes |
| Anything else | its text as bytes (`::text COLLATE "C"` / `CAST(… AS
BINARY)` / SQLite `COLLATE BINARY`) | bytes |

Integer and uuid keys, the common case, sort exactly as before. Text
keys now sort by bytes, which the server can't serve from the index, so
it sorts instead.

**Tests** (all fail on the old code, all pass with the fix)
- `StreamingMergeDiffTest` (SQLite, runs everywhere):
- a text key holding `'9'` and `'10'` gives one `INSERT`, not a delete
and re-insert;
  - `comparePK` follows the key type.
- `StreamingMergeServerTest`, PostgreSQL (ICU collation where available)
and MySQL: text keys mixing case and numbers give exactly the expected
inserts, deletes and updates.

Locally:
- Postgres suite: 225 passed.
- MySQL `DBDiff,Unit`: 1,083 passed.
- The 2M-row integer-key benchmark gives byte-identical output in the
same time.

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

…dles json (#267)

**Builds on #265 and #266.** Merge those first; until then this PR's
diff includes their commits.

Tables without a primary key were already diffed **correctly** at small
sizes, on PostgreSQL, MySQL and SQLite: whole rows are matched,
duplicates are counted, each `DELETE` removes exactly one copy (`ctid` /
`LIMIT 1` / `rowid`), and NULLs match with `IS NULL`. I checked each by
applying the migration and comparing. Three problems remained.

**1. Memory and time**
- Both tables were paged with `ORDER BY` every column, using `OFFSET`
(quadratic), and every row was held in PHP.
- A 501k-row keyless table took **77 s and 984 MB**; at 500k rows with
changed timestamps it ran out of the default 1G limit.

**2. json columns could not be diffed at all**
- PostgreSQL can't order `json`, so the paging query itself failed:
  > could not identify an ordering operator for type json

**3. The `DELETE` could not match a json value**
- PostgreSQL `json` (and `xml`, `point`, …) has no `=` operator.
- MySQL `JSON` compares unequal to a string.
- Dolt even reads JSON as `{"a":1}` but casts it to `{"a": 1}`.

**The fix**

**Phase 1:** each server groups its rows by a hash of the whole row and
counts them, in hash order:
```sql
SELECT h, n FROM (SELECT <hash of every column> AS h, count(*) AS n FROM t GROUP BY h) g ORDER BY h
```
- The two sorted streams are merged with the same `RowStream` as #265.
Different counts become that many inserts or deletes.
- Memory follows the number of distinct differences, not the table.

**Phase 2** runs only when something differs. It's one pass over each
side, picking up one copy of each row to insert or delete.

**json matching:** the catalog marks the columns with no plain equality,
and the `DELETE` matches them by text (PostgreSQL `::text`) or as JSON
(MySQL/Dolt `= CAST(… AS JSON)`). Other columns render exactly as
before.

**Measured** (PostgreSQL 17, PHP 8.3)

| Keyless table, 501k rows, 500 differ | Before | After |
|---|---|---|
| Time | 77.4 s | **4.4 s** |
| Peak memory | 984 MB | **107 MB** |

- The same statements as before, ordered by hash instead.
- Applying the UP makes the target identical to the source (row-set md5
compared).

**Tests**
- **`KeylessDataRoundTripPostgresTest`** (CLI, end to end): a keyless
table with duplicates, NULLs, `bytea`, `json` and `timestamptz`. The
generated UP must turn the target into the source and the DOWN must
restore it. On the old code it fails with the json ordering error above.
- **`StreamingMergeServerTest`**, PostgreSQL and MySQL:
  - the same round trip in-process;
  - a 400k-row keyless table must grow peak memory by under 25 MB.

Locally, all passing:

| Suite | Result |
|---|---|
| Postgres + Corpus | 383 passed |
| MySQL 8.0 `DBDiff,Unit` | passed |
| Dolt 2.2.3 `DBDiff,Unit` (as the Dolt job runs it) | passed |
| SQLite | 16 passed |
| Unit on PHP 8.4 / 8.5 | passed |

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