fix(db): skip SQLite-only migrations on Postgres

[ataliba]

Summary

All _migrate_* helpers in core/database.py assume SQLite unconditionally — they run PRAGMA table_info(...) / sqlite3.connect(db_path) straight against whatever DATABASE_URL is configured. On Postgres these either raise a caught-and-logged syntax error (PRAGMA isn't valid Postgres SQL) or silently no-op (the sqlite3.connect path treats a Postgres URL as a nonexistent file path and returns early) — either way the intended column/table changes never happen. Adds _is_sqlite() and an early-return guard at the top of every migration so they only run against a SQLite backend; Postgres installs already get the current schema from Base.metadata.create_all() at first boot, so these migrations are meaningless there and were only ever silently failing, never actually needed.

Verified against a real Postgres 17 deployment (192.168.68.22) that was hitting exactly the PRAGMA syntax errors described in the issue on every boot.

Target branch

• This PR targets dev, not main.

Linked Issue

Fixes #5941

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)

Checklist

• I searched open issues and open PRs — this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
• I actually ran the app and verified the change works end-to-end — deployed to a live Postgres-backed instance; the PRAGMA ... syntax error log spam on boot is gone and the app starts clean.

How to Test

1. Point DATABASE_URL at a Postgres instance with an existing (older) schema.
2. Boot the app.
3. Before this fix: logs show a wall of psycopg2.errors.SyntaxError: syntax error at or near "PRAGMA" on every migration call. After: none of those — each migration short-circuits via _is_sqlite() instead.
4. On a SQLite install, behavior is unchanged (migrations still run normally).

Visual / UI changes

• N/A — backend-only change, no UI/rendering touched.