[Pipeline C] Fix Form model, add migration and repo functions (#552, part 1)

[abhishek-8081]

Part 1 of #552 (the data layer; the generate endpoint, fill task, and retrieval endpoints
follow in later PRs).

Fixes the v1 Form model to match the form-record.yaml contract and the agreed design (forms
link the incident, not the extract; keyed by template; batch is a grouping key, no Batch
table):

• Add template_id (FK to form_templates) — forms are keyed by template; FormRecord requires it.
• Add batch_id (nullable UUID, no FK) — batch is derived on the fly from Form rows sharing a
  batch_id, per the scope decision (no Batch table in Single Form generation - API Contracts #552; Batch form generation - API Contracts #554 can add one if it needs it).
• Make incident_id required; drop extract_id (the extraction is reachable through the
  incident, so forms don't link it directly).

Migration 005 (down_revision 004) uses batch_alter_table for SQLite/Postgres portability.
Verified on both: the full suite (454) passes on SQLite, and I ran upgrade → downgrade 004 →
upgrade → alembic check against a real Postgres 17 container — all clean, so the FK
drop/re-add works with the actual Postgres constraint names.

Repository functions for the v1 Form model: create_generated_form, get_form,
list_forms_by_batch, update_form (named to avoid colliding with the legacy create_form, which
targets the old FormSubmission and is untouched).

Note: the downgrade re-adds extract_id as NOT NULL, which assumes the forms table is empty -
true now (generation isn't implemented yet), but a rollback caveat once the fill task lands.

@marcvergees @vharkins1 @chetanr25

[chetanr25]

LGTM!