BackupFreshnessCollector was wired with APP_ENV ('prod'), but backups are catalogued under
DefaultEnvironment::NAME ('production') — deliberately, so the catalog lines up with the deploy and
release manifests. Every catalog lookup therefore filtered on an environment no row has ever
carried. It found nothing, reported backup_present=0 for every engine, and because it
short-circuits when no backup exists it never emitted the age or size gauges at all.

Verified on a production installation holding 3042 WAL segments, 38 logical fulls and 13 physical
bases: backup_present=0 for both engines, and app_backup_last_success_age_seconds has never
existed. The backups were always fine. The monitor was the broken part.

That is the worst shape this failure can take. The freshness gauge is the one signal designed to
catch a backup that stopped running rather than started failing — the case where nothing throws, so
nothing alerts, and you find out at restore time. A threshold alert on an age series that is never
emitted cannot fire, so the dead-man switch was itself dead. DefaultEnvironment's own docblock says
it exists so "the default can never drift again"; this was the one reader that did not use it.

Engines were hardcoded to [Postgres, Mongo] too, inventing a permanently-red mongo series on a
stack that has no Mongo. Both now come from config/backup.php via the loader, through a factory,
because the config is only available at runtime — resolving it in the extension would re-read
config/backup.php independently, which is precisely the duplication that caused the drift.

Without a config file both engines are still reported: with nothing to narrow by, backup_present=0
is the honest answer to "is anything backing this up".

Split from ba4d545c84e02efdcbb85dc844253a282da3e87e