Add uploads table migration

[jpers1]

Summary

Add a migration that creates the uploads table for existing databases.

Why

The repository already defines uploads in the full database creation path, but existing databases created before that table existed do not receive it automatically because there was no corresponding runtime migration.

That causes runtime failures such as:

• SQLITE_ERROR: no such table: uploads

Changes

• add utils/db-migrations/003-add-uploads-table.sql
• create the uploads table if it does not exist
• add an index on answerId

Scope

This PR only addresses schema evolution for existing databases.

It does not change:

• application behavior
• upload API semantics
• the full schema creation path for fresh databases

Validation

• traced the error path to runtime queries against uploads
• verified the table exists in the full schema creation logic
• verified the runtime migration set did not previously include a migration that creates uploads

Notes

This is kept separate from the rendering fixes because it addresses a different class of problem: stale local database schema rather than content rendering.

[jpers1]

Reviewer note: this migration is only for existing databases. Fresh databases already get uploads through the full schema creation path; the gap was that older DBs never received the table through runtime migrations, which is what caused SQLITE_ERROR: no such table: uploads.

[janezd]

This PR adds a migration for a change that was implemented -- but not yet merged -- before migration mechanism existed. True, the PR that introduced uploads should had been rebased to the master that enabled migrations, and the migration should be provided. However, I missed this. I assume that not many (if any) users have a database without this table and would need this migration. If they do, it can easily be resolved by recreating the (local) database.

If I implemented migrations from the start (which I should have!) they would include creation of database and dozens of changes. At this point, retracing the entire history would make no sense.

Another, more important reason for rejecting this PR is that the migration is incorrect: the table needs to be populated with data extracted from table answers. When merging the PR that introduced uploads I actually (manually) ran such a migration.