v1.9.1 — Hotfix profile 500 + Gemini model dropdown

Two fixes

1. Profile page returned 500 after v1.9.0 deploy

_apply_lightweight_migrations ran every ALTER TABLE inside a single
db.engine.begin() transaction. Postgres aborts a whole transaction
on the first error — and from v1.8.1 onwards an earlier migration
(ALTER TABLE pending_captcha ALTER COLUMN response TYPE VARCHAR(32))
could fail on fresh databases. The aborted transaction silently
dropped every later statement, so v1.9.0's ADD COLUMN google_api_key never ran. Once the User model expected a column the
DB didn't have, any SELECT from /auth/profile crashed with a
PostgreSQL error and Flask returned 500.

Fix: each ALTER TABLE now runs in its own db.engine.begin() block.
A single failing migration no longer poisons the rest.

2. Configurable Gemini model

• Default model is now gemini-2.5-flash (Google moved
  gemini-2.0-flash to legacy-only in March 2026).
• The profile page gains a model dropdown under the API key
  field. Options: gemini-2.5-flash, gemini-2.5-pro,
  gemini-2.5-flash-lite, gemini-2.0-flash. New nullable column
  user.gemini_model stores the per-user choice.
• LLMVisionSolver reads the user's preferred model at call time
  and falls back to DEFAULT_MODEL if not set.

Image

ghcr.io/gonzalez8/checktime:1.9.1 / :1.9 / :latest

Upgrade

sed -i 's/^CHECK_TIME_VERSION=.*/CHECK_TIME_VERSION=1.9.1/' stack.env
docker compose pull app
docker compose up -d app

Migration is auto. After the restart, the profile page should load
again. Users who already had v1.9.0 with the missing google_api_key
column will see it created on first boot of v1.9.1.

Verifying the fix

docker compose exec db psql -U $POSTGRES_USER $POSTGRES_DB -c \
    "\d \"user\"" | grep -E "google_api_key|gemini_model"

Should list both google_api_key (varchar 512) and gemini_model
(varchar 64). If you saw the 500 before, both columns will appear
the first time you boot v1.9.1.