status should surface applied DB versions missing from the migration directory
Description
Currently goose status appears to enumerate local provider/filesystem migrations and then checks DB metadata for each local version. As a result, if goose_db_version contains an applied version that is absent from the current local migration directory, goose status does not show that applied DB row at all.
This is surprising for production operations: the command is named status and connects to the production DB, but the reported status can silently omit actual production-applied migrations depending on the operator's local checkout.
This is not the existing allow-missing / out-of-order case. allow-missing handles local migrations that are lower than the DB max version and not applied in DB. This issue is the opposite direction: applied in DB, missing locally.
Expected behavior
goose status should either:
- include DB-only applied versions with a state like
Applied, source missing, or - fail/warn when applied DB versions are not present in the migration source.
Observed behavior
DB-applied versions absent from local files are omitted from status.
Why this matters
For production environments, goose status is often used as an operational truth check. If it silently depends on the exact local checkout and hides applied DB rows that the checkout does not know about, an operator can incorrectly conclude that production and local migration state are aligned.
Related context
This is adjacent to, but different from, existing out-of-order/missing migration discussions:
Source: pressly/goose