… FKs

MySQL has no in-place RENAME CONSTRAINT or RENAME FOREIGN KEY, so the
diff still emits DROP+ADD for both. But threading the directive
through gives the user a typo guard: a `-- myschema:renamed-from`
whose source name doesn't exist on the current side aborts the plan
with `renamed-from: source ... not found in current schema` instead
of silently dropping + re-adding the wrong target.

Implementation mirrors the existing column / index rename path:
- `model.Constraint` and `model.ForeignKey` gain a `RenameFrom *string`.
- `parser.classifyInlineLine` distinguishes the four named-constraint
  shapes by looking at the keyword after the name: UNIQUE → index
  (existing), CHECK → new inlineKindCheck, FOREIGN → new inlineKindFK.
  The catch-all `inlineKindConstraint` is removed (UNIQUE / CHECK /
  FOREIGN KEY cover every named CONSTRAINT shape MySQL accepts).
- `parser.InlineRenames` gains `Constraints` and `ForeignKeys` maps;
  `ParseSQL` attaches them to the corresponding model entries the
  same way it does for columns and indexes.
- `diff.validateConstraintRenames` / `validateForeignKeyRenames` run
  inside `diffTable` after the column / index rename passes. They
  enforce the same shape rules as the rename ALTER passes
  (duplicate source, source-also-declared, source-not-found,
  destination-already-exists, idempotent re-apply) but emit no
  statements — the natural diff path produces the DROP+ADD.

Tests:
- parser: TestExtractInlineRenamesCheckConstraint /
  TestExtractInlineRenamesForeignKey assert the new routing;
  TestParseSQLAcceptsConstraintRenameDirective /
  TestParseSQLAcceptsForeignKeyRenameDirective cover the
  parser→model attach. The previous "constraint is unsupported"
  expectations are flipped (or removed where they no longer apply).
- diff: TestDiffRenameConstraintMissingSourceErrors /
  TestDiffRenameForeignKeyMissingSourceErrors lock in the typo-guard
  error path.
- end-to-end YAML fixtures (`testdata/apply/`) for the happy path on
  both CHECK and FK with `verify_no_drift: true`, plus a
  `testdata/plan/` fixture for the typo error.

Verified on mysql 8.0 + 9.4: full Go suite, YAML harness, scenario
suite, lint all green.

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

edge paths

PR #37's first cut only pinned the source-not-found path on each side.
Add the duplicate-source and source-also-declared paths too — both
mirror the existing column / index rename validation but lived
without dedicated coverage for the constraint / FK side.

- TestDiffRenameConstraintDuplicateSourceErrors / …ForeignKey…
  Two desired-side entries claim the same RenameFrom; without the
  guard the second would surface as a confusing "source not found"
  after the first apply consumed the source row.
- TestDiffRenameConstraintSourceAlsoDeclaredErrors / …ForeignKey…
  Desired declares both the source name and the destination
  (renamed-from source); without the guard the diff would DROP+ADD
  the destination and then ADD the source, almost certainly not
  what the user meant.

Parser-side `target … not found in CREATE TABLE` paths were
considered but are unreachable in practice — `ExtractInlineRenames`
and `parseCreateTable` resolve the same name through different code
but normalised the same way, so the error never fires for any
input that survives parsing. CLAUDE.md explicitly tells us not to
write unnatural tests for unreachable defensive code, so they're
intentionally omitted.

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

Two valid nits:

- diff/rename.go: validateConstraintRenames docstring said "the
  natural diff path produces the DROP CONSTRAINT + ADD CONSTRAINT".
  For CHECK constraints diffConstraints actually emits
  `DROP CHECK <name>` (not MySQL's `DROP CONSTRAINT` syntax) plus
  `ADD CONSTRAINT <name> CHECK (...)`. Update the wording so it
  matches the emitted DDL.
- parser/parser.go: rejectMisplacedRenameDirectives only inspected
  inline.Columns / inline.Indexes / inline.Unsupported, but
  ExtractInlineRenames now also fills inline.Constraints and
  inline.ForeignKeys for the new CHECK / FK directive paths. Without
  that, an inline CHECK or FK rename directive sitting in a
  non-CREATE-TABLE statement could in principle slip through
  silently. Extend the guard to cover both new maps so the
  consistency invariant ("any non-empty inline-renames map on a
  non-CREATE-TABLE statement is an error") holds across all five
  buckets.

No new tests for the parser-side change: the only inline shapes
classifyInlineLine routes to Constraints / ForeignKeys are
`CONSTRAINT name CHECK` / `CONSTRAINT name FOREIGN KEY` lines,
which only appear inside CREATE TABLE bodies in any SQL the project
parses. The reachable regression already lives in the existing
TestParseSQLRejectsRenameDirectiveOnCreateView; expanding it with
artificially-constructed inline cases would be an unnatural test of
unreachable defensive code (per CLAUDE.md).

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

Both classifyInlineLine CONSTRAINT branches said "Distinguish the
four named-constraint shapes" but the switch only handles three
(UNIQUE / CHECK / FOREIGN). The fourth shape that fits the comment
is `CONSTRAINT name PRIMARY KEY (...)` — legal MySQL syntax, but the
user-supplied name is ignored in favour of the fixed "PRIMARY", so
the directive on it can't drive a real rename and the code
intentionally falls through to "unknown".

Reword both comments as "rename-eligible named-constraint shapes" and
explicitly call out `CONSTRAINT name PRIMARY KEY` as the unhandled
fourth so a reader doesn't think a switch case is missing.

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