…/KEY count changes

Builds on PR #50's RANGE/LIST suffix add + subset drop. HASH /
KEY (incl. LINEAR HASH and LINEAR KEY, as well as KEY
ALGORITHM=N) now produce real DDL when the partition strategy
is unchanged and only `PARTITIONS n` differs:

- count grow → `ALTER TABLE … ADD PARTITION PARTITIONS n`
  (n = desired - current). No data loss; new slots are empty
  until the next rebalance.
- count shrink → `ALTER TABLE … COALESCE PARTITION n`
  (n = current - desired). MySQL rebalances rows from the
  dropped slots into the survivors, but the slots themselves
  go away — gated on `--allow-drop=partition` like RANGE/LIST
  DROP. Without the flag the COALESCE lands on the disallowed
  bucket as a `-- skipped:` line.

Equal counts already returned no-op (round 4); scheme mismatch
(Type / IsLinear / KeyAlgorithm / ColList / Expr) still falls
through to "scheme/expression differs" upstream.

Implementation: diff/partitions.go's HASH/KEY branch (which
previously returned the unsupported-diff error) now emits the
two count statements. partitionHeaderEqual already covers
LINEAR / KEY ALGORITHM via its IsLinear and KeyAlgorithm
fields, so no new normalisation is needed.

Tests:
- 5 plan fixtures: HASH grow, HASH shrink with allow_drop,
  HASH shrink disallowed, KEY grow, LINEAR HASH grow.
- 2 apply fixtures with verify_no_drift: HASH grow, HASH
  shrink. Pin that the generated DDL runs on MySQL and the
  next plan reports no drift.
- 2 diff unit tests: KEY grow (ADD PARTITION PARTITIONS),
  KEY shrink with vs. without allow-drop=partition.
- Replaced TestDiffPartitionsKEYCountChangeStillErrors (which
  pinned the old error) with the grow / shrink pair above.
- Removed testdata/plan/partition_hash_diff_errors.yml (same
  reason — count-change is no longer an error).

Docs:
- CAVEATS.md "Partitioning" moves the HASH/KEY count change
  from "Diffs that still error" to "Diffs that *are*
  generated".
- AGENTS.md "In scope" lists the count-change shape; the
  "Not yet implemented" entry no longer mentions HASH/KEY.
- TODO.md entry updated to reflect what's left (REORGANIZE,
  scheme change, add/remove partitioning).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ge wording

Six wording nits, all my MySQL-knowledge mistake. Increasing
PARTITIONS changes the hash modulus, so MySQL has to
redistribute existing rows during the ALTER — new partitions
do NOT stay empty. COALESCE PARTITION likewise merges
partitions and redistributes rows into the survivors; it
does NOT discard rows. So:

- HASH/KEY grow: data-moving (rows redistributed across the
  new modulus), but no row loss.
- HASH/KEY shrink: data-moving (rows merged into the
  survivors), but no row loss.

The `--allow-drop=partition` gating on COALESCE stays — the
slot structure changes irreversibly and the operation is
operationally heavy / expensive — but the justification is
"destructive at the slot level" rather than "destructive at
the row level". Reword every comment / doc bullet that
implied row loss or empty new partitions:

- CAVEATS.md "Partitioning" HASH/KEY count change bullet
  rewritten to spell out the data-moving behaviour and the
  irreversibility-based gating reason.
- diff/partitions.go: docblock summary, the inline branch
  comment, and the gating-justification line all reworded.
- diff/partitions_test.go: KEY shrink test comment.
- testdata/plan/partition_hash_count_grow.yml and
  partition_hash_count_shrink_with_allow.yml fixture headers.

No implementation change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

I confirmed the COALESCE / ADD PARTITION PARTITIONS docs against
the MySQL 8.0 manual. The round-2 wording correctly noted both
operations are row-preserving and data-moving, but it described
the cost as if the table always uses regular HASH/KEY where the
modulus changes and most rows shift partition. That overstates
the cost for LINEAR HASH / LINEAR KEY users.

Per dev.mysql.com/doc/refman/8.0/en/partitioning-linear-hash.html
the linear-powers-of-two algorithm makes "adding, dropping,
merging, and splitting of partitions … much faster" because only
the partitions adjacent to the change need to be touched. That's
the headline reason for picking LINEAR over regular at table-
creation time, so the docs shouldn't read as if myschema
collapses both into the same heavyweight rewrite.

CAVEATS.md "Partitioning" HASH/KEY count change bullet, the
diff/partitions.go docblock and inline branch comment, and the
two HASH fixture headers all now spell out:

- both directions are row-preserving but data-moving;
- regular HASH/KEY rewrites most of the table (modulus shift);
- LINEAR HASH/KEY touches only the adjacent partitions and is
  "much faster" per the manual;
- the `--allow-drop=partition` gating on COALESCE is about the
  slot structure changing irreversibly, not about row loss.

No implementation change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>