fix(yaml_loader): refresh stale table cache on miss during config apply

[ddavignon-hadrian]

Problem

Fixes #2150.

When applying declarative YAML config, change_retentions resolve their source/destination tables against the tables list cached on the postgres_databases record. That cache is only refreshed when a database is created and by the 6-hourly EnqueueDatabaseUpdateWorker cron — the config-apply update path (update_db/2) never refreshes it. So if a table is created after the last refresh, apply_config fails with:

No `table` found matching params: `name=..., schema=public`

Because config apply runs at container start (before start_application), this fails the boot and crash-loops the container, which in turn prevents the 6-hourly cron from ever running — so the deployment can't self-heal. (Full analysis in #2150.)

Fix

Refresh the referenced database's tables from the live database on a cache miss while parsing change_retention attrs, then retry the lookup (option 1 from the issue). A new ensure_table_cached/3 helper:

• returns the database unchanged on a cache hit (existing in-memory fast path — no extra round-trip);
• on a miss, calls Databases.update_tables/1 once to refresh from the live DB, preserving the replication_slot preload;
• still returns not_found if the table is genuinely absent after refreshing (no behavior change for real misses).

A round-trip is only added when a referenced table is missing from the cache, so applies that don't reference new tables are unchanged.

Test

Adds a change_retentions test that creates a database, clears its cached tables to simulate a stale cache, then applies a config whose change_retention references those tables and asserts the apply succeeds and the pipeline is created.

[ddavignon-hadrian]

Quick heads up on the failing signoff check: it died at the Configure PostgreSQL step with psql: command not found (exit 127) on the warp-ubuntu-latest-arm64-32x runner. That's a setup step, so nothing after it ran and the Elixir compile and tests were skipped entirely. I don't think it's related to this PR, which only changes lib/sequin/yaml_loader.ex and its test.

Looks like the runner is missing the postgres client. Could a maintainer re-run it once that's sorted?

In the meantime I ran it locally on Elixir 1.19.4 / OTP 28.3 against Postgres 17 with pgvector and logical replication. The project compiles clean and the new test passes. I also checked that the test fails without the fix, with the same "No table found matching params: name=sequin_events, schema=public" error from the linked issue, so it reproduces the bug and the change resolves it.

Happy to change anything on my side if it's needed.