Tier 2 red: Story346 real-Postgres verify probe expects db/46's marker that the container never gets

[genwave-radio]

🔴 What

The first nightly run (https://github.com/GenWave-Org/genwave/actions/runs/35148817710, job integration) fails one fact of the 540 in the Host tier-2 run:

Story346_AdoptionVerifyRepair › ScenarioRealPostgresProbe.VerifyMigrationsAgainstARealPostgresContainerSucceedsAsTheContainersOwnRole

It expects setup.sh --verify against a real Postgres container to print current through db/46. The verify instead prints:

⚠️  Schema migrations   Repo's db/ max is db/46, but its marker (station.sponsor) is missing from the schema — this box may be behind.

So the psql probe itself works as the container's own role (the fact's original point) and the drift is in what the fact pins: the container the fact spins up does not carry the db/46 marker table.

📅 Not new

The same failure is in the dev box's own trx from 2026-09-08 (tests/GenWave.Host.Tests/TestResults/host_run3.trx, host_run4.trx), so it has been red locally since at least then. Tier 2 never ran in CI before the nightly existed, which is why nobody saw it.

🛠️ To do

• Work out why the real container lacks station.sponsor after the fact's own migration step (db/06 fresh-init mirror vs db/46, see db/06 fresh-init mirror is missing station.schedule_special (db/36) #618 for the family) and fix the fixture, or re-pin the fact's expected marker if db/47 changed the derivation.
• The fact's comment block documents that it needs re-pinning whenever a new CREATE TABLE migration lands; consider deriving the expected marker in the spec the same way verify_derive_migration_marker does, so it stops rotting.

Surfaced by the nightly (gh-#777, STORY-449); it is one of the two reds behind the first nightly-red issue #795. The other is the chaos leg, handled by the F178.8a bound (gh-#791).