fix(tests): run the maintenance-routine e2e against the current routine body (#3680)

`test_routines_callable_from_non_public_schema` installs the routines into a
non-public schema and then CALLS one, but it loaded the bodies from
`b6d2f8a4c1e7` — superseded since. #2638's install gating is what the test is
about and that has been carried forward unchanged, but the bodies have not:
`c8b4e2a71f95` gave each per-schema query a `lock_timeout` and skip arms
precisely because the older body waits indefinitely for AccessShareLock on
every schema it scans, and a peer's concurrent DROP then closes a lock cycle.

So the test kept exercising the one body no deployment runs, and under xdist —
where peer workers create and drop schemas continuously — PostgreSQL kept
picking it as the deadlock victim. Recurring `DeadlockDetectedError`, most
recently on main's own run 32142821174.

Measured with the victim schema held under ACCESS EXCLUSIVE from a second
connection: the b6d2f8a4c1e7 body blocks until the DDL commits, the current one
returns immediately having skipped it.

Resolve the migration from the revision chain (Alembic's `walk_revisions`, so
merge revisions resolve correctly) rather than hard-coding it, and add a guard
asserting whichever migration owns the bodies still carries the skip arms —
the point being that a fix to the routine must reach the test that reports the
bug. `_load_schema_local_migration` stays pinned for the two tests that assert
what that migration's install gating emits.