v0.9.9-beta fails to start on a v0.9.8 volume: "no such column: async_tasks.payload" (Alembic migration never runs, alembic_version missing)

Bug type

Backend / startup

Summary

The ghcr.io/presenton/presenton:v0.9.9-beta image (digest sha256:e1640d671e6c321021cf4096f5deb5e1c5da26b6a6881499911b531842b0d8b0, created 2026-09-02T18:13Z) does not start on an app_data volume that was created by v0.9.8-beta. It crash-loops with:

sqlite3.OperationalError: no such column: async_tasks.payload
[SQL: SELECT async_tasks.id, async_tasks.owner_id, async_tasks.type, async_tasks.status, async_tasks.message, async_tasks.error, async_tasks.data, async_tasks.payload, async_tasks.created_at, async_tasks.updated_at ...
ERROR:    Application startup failed. Exiting.

The 0.9.8 database has no alembic_version table (the schema was evidently created with create_all, never stamped). On 0.9.9 startup no Alembic migration runs at all: the new api_keys table appears (metadata create_all adds new tables) but async_tasks.payload is never added, because create_all does not alter existing tables and migration 026c0ba8b35c_add_async_task_payload_and_unified_api_keys never executes. The ORM then selects the missing column and startup aborts.

I know v0.9.9-beta has no GitHub release yet; reporting because the tag is already on ghcr and :latest users will hit this as soon as it is promoted.

Steps to reproduce

1. Run v0.9.8-beta with a fresh ./app_data, create the admin, generate one presentation (so async_tasks has rows).
2. Stop it, start v0.9.9-beta on the same app_data (docker run -v ./app_data:/app_data ghcr.io/presenton/presenton:v0.9.9-beta).
3. Container exits with the traceback above; docker ps shows Restarting.

Observed DB state, before → after the failed start:

• pragma table_info(async_tasks): id, owner_id, type, status, message, error, data, created_at, updated_at → unchanged (no payload)
• alembic_version table: absent → still absent
• tables api_keys, access_tokens: access_tokens only → both present (so create_all ran, Alembic did not)

Reproduced twice, the second time on a copy of the volume with --network none.

Expected behavior

Upgrading 0.9.8 → 0.9.9 on an existing volume should either run the Alembic migrations (stamping an unstamped legacy database first), or the model/migration should not depend on a column that create_all cannot add.

Presenton version

v0.9.9-beta (ghcr image, created 2026-09-02T18:13Z); working baseline v0.9.8-beta (sha256:e6866086…)

Operating system

Debian 13 (host), Docker 29.8

How are you running Presenton?

Docker (docker run, single container, bind-mounted app_data)

LLM provider

OpenAI (not relevant — fails before any provider call)

Additional information

Rolled back by restoring the pre-upgrade app_data tarball and starting the 0.9.8 container again; no data lost. Happy to test a fixed image against the same volume.