fix: order no_phase operations after the objects they act on

[MayCXC]

Problem

An operation flagged no_phase: true carries no implicit ordering, so without a requires/1 clause it floats ahead of the phased operations that build a table's structure. Two such operations render SQL against an object another operation creates in the same batch, so floating puts them before that object exists:

• AlterDeferrability (ALTER CONSTRAINT ... DEFERRABLE) runs against a foreign key an AddAttribute carrying references: creates. When a composite with: key pushes the foreign key into a later phase, the deferrability alter ran first and failed with constraint ... does not exist.
• AddPrimaryKey (ADD PRIMARY KEY (keys)) runs against key columns an AddAttribute can add in the same batch. Widening a primary key to include a newly added column (list-partitioning by that column, for instance) generated ADD PRIMARY KEY (id, cell_id) before cell_id existed.

Fix

Give each a requires/1 clause: AlterDeferrability{direction: :up} requires table_columns_settled; AddPrimaryKey requires column_ready for each key column. Both requirements are vacuous when the object predates the batch (nothing in the batch provides the fact), and neither adds a cycle: each provides only table_structure_ready, which AddAttribute never requires.

This builds on the dependency-graph model from #798, and is a distinct case from the composite-primary-key work in #805, which addressed the streamline merge and the DropForeignKey{direction: :down} phase split rather than ADD PRIMARY KEY over a newly added column.

The class

The module doc now documents the whole class, so future no_phase operations are held to it. The rest are already safe: they act on objects that predate the batch (RenameTable, MoveTableSchema, RemoveCustomIndex, and the other renames and drops), render nothing in up (the *Down helpers), or are ordered by the consumers that require their facts.

Tests

Reproducing tests for both fixes in operation_deps_test.exs, at both the requires/provides level and the toposort_operations/1 level. Each fails without its requires clause (verified by neutralizing the clause).

• Full test suite passes.
• mix ash_postgres.generate_migrations --check is clean for both PG variants, so no checked-in migration reorders.

[zachdaniel]

I think a lot of the comments/docs in this PR can be trimmed down significantly. Would you mind making that change? Otherwise LGTM

[MayCXC]

sure 092c37c

[zachdaniel]

🚀 Thank you for your contribution! 🚀