Procrastinate schema migration tracks installed lib version instead of frozen SQL

Follow-up from #162 (detection-review chunk 1).

Observation

The alembic migration a7b8c9d0e1f2_procrastinate_schema.py applies the procrastinate queue schema by calling SchemaManager.get_schema() at runtime (drop-then-recreate, idempotent), rather than embedding a frozen SQL snapshot like a normal alembic migration.

Implication

The migration's effect depends on the installed procrastinate version (pinned range >=2.0.0,<4.0.0), not on the migration file. Because it is idempotent drop-then-recreate, this is robust for a fresh DB or the test harness reset. But:

• Alembic tracks this migration as "already applied" after the first run, so if procrastinate is later upgraded to a version with a changed schema, re-running alembic upgrade will not pick up the new schema — you'd need to author a fresh migration.
• Procrastinate normally ships its own migration tooling (procrastinate schema --apply / its own migration files); we bypass that here.

Options to consider

1. Leave as-is and remember to add a new migration on any procrastinate schema-affecting upgrade (document in upgrade notes).
2. Adopt procrastinate's own migration workflow instead of the single get_schema() migration.
3. Freeze the current schema SQL into the migration so it is version-pinned like the rest.

Notes

• Not currently broken; this is about future upgrade hygiene.

Start with alembic migration a7b8c9d0e1f2_procrastinate_schema.py and trace its call to SchemaManager.get_schema(). Compare that approach with procrastinate schema --apply and the package's migration files; done means selecting and documenting a version-safe strategy, including any needed upgrade notes or new migration coverage.