Repair SQLite vendor tables whose id column no longer auto-increments

[cycsmail]

Fixes #1131

SQLite only hands out ids automatically for a column declared exactly as a single-column INTEGER PRIMARY KEY (a rowid alias). Our migrations create vendor.id that way, but a database that has been through an export/convert round trip (a BIGINT id, or a primary key that got dropped on the way) comes back without the alias, and from then on every INSERT INTO vendor that doesn't carry an explicit id fails with NOT NULL constraint failed: vendor.id, which is the traceback in the issue. Reads and updates keep working, matching what was reported.

This adds a migration that, on SQLite only, checks PRAGMA table_info('vendor') and, if the id isn't a single-column INTEGER primary key, rebuilds the table through alembic's batch mode with the schema the initial migration always intended, keeping every row, the filament/vendor_field references and ix_vendor_id. Healthy databases are left untouched (it's a single PRAGMA read), other database types return immediately. I couldn't see the reporter's actual schema, but a non-alias id is the only way SQLite produces this error on an insert without an id, so the check covers the shapes a conversion can leave behind. Only vendor is touched since that's what was reported; if a converted db turns out to have the same problem on filament/spool the same check can be generalised.

How I've tested it: a new unit test upgrades a temp sqlite db to the previous revision, rewrites the vendor table with a BIGINT id (which reproduces the exact IntegrityError), then upgrades to head and checks that inserts auto-increment again continuing after the existing ids, that the existing vendors plus a filament and a vendor_field pointing at them survive, that PRAGMA foreign_key_check is clean and the index is back. A second test checks a healthy db's vendor schema is byte-identical before and after. pytest tests passes (275 tests), ruff check and format are clean on the new files.