AGENTS.md "In scope (v1)" lists "inline column-level PK / UNIQUE /
REFERENCES", but only the REFERENCES path was actually wired up
(parser/parser.go's column loop checked `cd.Type.Options.Reference`).
vitess parses `id INT PRIMARY KEY` and `email VARCHAR(255) UNIQUE`
as a column attribute (`cd.Type.Options.KeyOpt = ColKeyPrimary` /
`ColKeyUnique` / `ColKeyUniqueKey`) rather than promoting them to
the table-level Indexes / Constraints buckets, so both forms were
silently dropped. Plan / apply / dump confirmed (`SHOW CREATE
TABLE` after apply showed neither the PK nor the UNIQUE index).

Add `applyInlineColumnKey` to mirror the table-level path's
behaviour from `addIndex`'s IndexTypePrimary / IndexTypeUnique
cases:

- `ColKeyPrimary` → PRIMARY constraint + PRIMARY index, with the
  column forced to NotNull (MySQL silently does that for PK
  columns; mirror so the dump round-trip stays stable).
- `ColKeyUnique` / `ColKeyUniqueKey` → UNIQUE index named after the
  column (matches MySQL's auto-naming and the table-level UNIQUE
  case at parser.go's IndexTypeUnique branch).
- Other ColKey* values (None, Spatial, Fulltext, bare Key) aren't
  valid column-level MySQL attributes — pass through silently to
  match the parser's existing "ignore unmodelled shapes" policy.

Tests: TestParseInlineColumnPrimaryKey / TestParseInlineColumnUnique
in parser_test.go pin the parsed model. Integration fixture
testdata/apply/inline_column_primary_key_and_unique.yml exercises
the full plan → apply → re-plan-empty round-trip; without the fix
the inline PK / UNIQUE silently drop and verify_no_drift catches
the regression.

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

- applyInlineColumnKey: rewrite the duplicate-handling comment.
  The previous text claimed addIndex's IndexTypePrimary case has an
  "existing PRIMARY KEY equality check" that would let the duplicate
  through — that's wrong, addIndex unconditionally overwrites
  Constraints["PRIMARY"] / Indexes["PRIMARY"]. The skip is still
  correct (same end state when both forms reference the same column,
  MySQL-rejected at apply when they don't); explain that instead.
- TestParseInlineColumn{PrimaryKey,Unique} comments referenced
  parser.go:608 / parser.go:617. Replace with stable references
  ("addIndex's IndexTypePrimary case", "addIndex's IndexTypeUnique
  case") so the comments don't rot when the file is edited.

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

Coverage gap audit on the inline column-level PK / UNIQUE work:

- New `AUTO_INCREMENT combines with inline PRIMARY KEY` sub-test
  pins the most common real-world surrogate-key shape
  (`id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY`). vitess holds
  KeyOpt and Autoincrement on different fields, so the promotion
  must not clobber AutoIncrement — pin so a refactor that mishandles
  the column attributes surfaces in CI.
- New `two inline PRIMARY KEYs: first column wins` sub-test reaches
  applyInlineColumnKey's idempotent skip branch (previously
  uncovered — vitess parses two-inline-PK SQL without error even
  though MySQL rejects at apply, so the second column hits the
  skip-when-exists guard). Pins the parser-side "first wins"
  precedence; MySQL still surfaces the duplicate-PK at apply.
- Document the dup-index guard in applyInlineColumnKey's
  ColKeyUnique case as defensive: it's unreachable in the current
  architecture (column loop runs before table-level Indexes; column
  names are unique-checked upstream), kept for symmetry with
  addIndex's IndexTypeUnique branch and to fail closed under a
  future pass-order refactor.

applyInlineColumnKey coverage: 84.6% → 92.3%. The remaining 7.7%
is the documented unreachable defensive branch.

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

The previous comment opened with "Both columns get NotNull forced"
which is wrong — only column `a` (the first inline PK) gets the
forced NotNull from its own promotion. Column `b` hits the skip
branch in applyInlineColumnKey and is left untouched; its NotNull
flag stays at whatever vitess parsed (here, implicit nullable INT
because the source SQL doesn't write NOT NULL on `b`).

Reword so the lead matches the rest of the comment instead of
contradicting it.

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