Evaluate alembic-utils-extended for materialized view + index management

Spinning out from #292 review (cc @MoralCode).

Stock `alembic_utils` ships `PGMaterializedView` for view definitions but doesn't track indexes. That's intentional, indexes are out-of-band for the library. PR #292 wraps it in a small dataclass that adds `unique_index_columns`, used by the refresh task to pick between `REFRESH MATERIALIZED VIEW CONCURRENTLY` and the non-concurrent path.

@MoralCode flagged [candidhealth/alembic-utils-extended](https://github.com/candidhealth/alembic-utils-extended), a fork that adds native index support via SQLAlchemy index types. Worth a real look so we stop carrying `unique_index_columns` ourselves.

Three options:

1. **Adopt candidhealth's fork.** Cleanest if it sticks, but 19 stars / 1 fork and last commit Dec 2025. hard to tell "stable and active" from "abandoned and stable."
2. **Add index support to stock `alembic_utils` and try to upstream.** If it lands, no fork at all. If the maintainer's slow, we vendor.
3. **Keep the wrapper.** ~10 lines; cost is just keeping `unique_index_columns` in sync with the DB.