Alembic op.drop_table leaves PostgreSQL enum types behind, must DROP TYPE explicitly

When SQLAlchemy/SQLModel creates a table with an sa.Enum(...) column against PostgreSQL, the database auto-creates a backing named type (e.g. passwordresetstatus). op.drop_table removes the table but leaves the enum type in place. A later migration that recreates a table with the same enum name fails with type "..." already exists, and a downgrade that recreates the original table hits the same duplicate-type collision unless the preceding upgrade dropped the type. Verified 2026-04 against PostgreSQL + alembic + sqlmodel.

In any Alembic migration that drops a table containing sa.Enum columns, follow op.drop_table(...) with op.execute("DROP TYPE IF EXISTS ") for each enum that table owned. Mirror inversely in downgrade() only if the new upgrade would collide. Verify enum names by inspecting the original CREATE TABLE migration or psql \dT.