Support postgresql_include for create_primary_key / create_unique_constraint

[anneheartrecord]

Fixes #1723

Problem

postgresql_include (added in SQLAlchemy 2.0.41 for PrimaryKeyConstraint / UniqueConstraint) was only wired up for create_index. Using it via the op directives failed in two distinct ways:

• op.create_primary_key(..., postgresql_include=[...]) raised TypeError: create_primary_key() got an unexpected keyword argument 'postgresql_include' because the public operation method did not accept dialect-specific keyword arguments.
• op.create_unique_constraint(..., postgresql_include=[...]) raised KeyError during DDL compilation: SQLAlchemy's _define_include looks the INCLUDE columns up in constraint.table.c, but those columns are not present on the synthetic table Alembic builds for the ALTER ... ADD CONSTRAINT statement.

Fix

• CreatePrimaryKeyOp.create_primary_key now accepts **kw, so dialect-specific kwargs flow through to the constraint (the rest of the op pipeline — __init__, to_constraint, from_constraint, and SchemaObjects.primary_key_constraint — already passed them through). create_unique_constraint already accepted **kw.
• PostgresqlImpl.add_constraint now appends any postgresql_include columns referenced by name to the constraint's synthetic table before emitting AddConstraint, mirroring the existing handling in create_index. The shared logic is extracted into a small _ensure_include_columns helper used by both create_index and add_constraint.
• Regenerated the .pyi / base.py operation stubs via tools/write_pyi.py (validated by tests/test_stubs.py).
• Added a changelog fragment at docs/build/unreleased/1723.rst.

Tests

Added test_create_unique_constraint_postgresql_include and test_create_primary_key_postgresql_include to tests/test_postgresql.py, asserting the emitted DDL:

ALTER TABLE t ADD CONSTRAINT uq_t UNIQUE (c1, c2) INCLUDE (inc)
ALTER TABLE t ADD CONSTRAINT pk_t PRIMARY KEY (c1, c2) INCLUDE (inc)

Both fail on main (TypeError / KeyError respectively) and pass with this change. Full suite: 1769 passed, 129 skipped (DB-specific). flake8, black, mypy, and the stub-consistency test all pass.

[MohammedAlkindi]

Checked this out and ran it on Windows 11, CPython 3.13.13, against main at c116cbc0.

Test evidence:

pytest tests/test_postgresql.py	result
this PR	71 passed
product change reverted, new tests kept	2 failed, 69 passed

The two failures with the product reverted are exactly this PR's new tests, so they discriminate the change. No existing test moved. (These are op_fixture("postgresql") SQL-string assertions — no live server involved, which is what let me run them on a bare Windows box; the actual PostgreSQL DDL round-trip is CI's to confirm.)

The refactor is a genuine improvement over the pre-existing code, not just an extension. The old inline loop in create_index appended Column(col, NullType) without checking the element type; the extracted _ensure_include_columns adds isinstance(col, str) before the in table.c test, and guards table is None. Centralising it also means create_index and add_constraint can't drift apart, which is how this class of bug (#1723) happened in the first place.

Two small questions:

1. postgresql_include on an index can contain Column objects as well as names (SQLAlchemy accepts both). The new isinstance(col, str) skips non-string elements — correct for the append (a real Column needs no synthesizing), but worth confirming the INCLUDE clause still renders for a Column element passed to create_primary_key, since the test matrix here covers the string form only.
2. const.dialect_kwargs.get("postgresql_include", None) or () — the or () folds an explicitly-empty list and None together, which is fine today; if SQLAlchemy ever distinguishes "empty INCLUDE" from "no INCLUDE", this line will hide it. A comment or a plain if would make the intent explicit.

The version-gate note (SQLAlchemy 2.0.41 for constraint-level postgresql_include) in the comment matches the changelog entry, and the docs update covers both new call sites.