status should surface applied DB versions missing from the migration directory

[dolzenko]

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:

• Raise an error when missing (pending) migrations are detected #279
• Add the ability to apply missing (out-of-order) migrations #280
• improve Status performance; add ability to retrieve latest N migrations #282
• feature: add additional columns to goose table #288
• Rethinking -allow-missing (out-of-order) migrations #523