chore(submodule): bump backend to 099fc84 (NEH-105)

[juancobo]

Advances the backend pointer to the current dev tip. Gitlink only — no other files change.

backend   874cdd2 → 099fc84
frontend  387a291 (unchanged, already level with its dev tip)

backend (2 commits)

• collections table has 3 DB columns the ORM model doesn't declare #123 — collections.export_version, last_exported_at and last_export_hash are dropped. They had been in the database since dda9bc1bc608 (May) without ever being declared on the Collection model, so every --autogenerate proposed deleting them; the record_annotations migration hit exactly that on 22 July and the drop had to be removed by hand. They are dropped rather than modelled because export state already lives on the filesystem — the download endpoint resolves the latest export by globbing collection_{id}_{timestamp}.zip — and because when export needs real persistence (BagIt export is synchronous, stages a full copy through /tmp, and never prunes old exports #108's async jobs and pruning) it will want one row per export, not latest-only columns on the parent. (backend Capture manifest written to the raw project path while images go to the sanitized path #63)
• pixi run db-check-drift (alembic check after db-upgrade), plus the docker compose exec equivalent and sharpened migration-review guidance in DEVELOPMENT.md.

This closes #58 (Backend build, deps & schema hygiene) — #123 was its last open child.

Verification. Against a dev database at head: the three columns held export_version = 0 with the other two NULL, so nothing was lost; alembic check then reported No new upgrade operations detected, confirming these were the only disagreement between the models and the database; and a downgrade -1 / upgrade head round trip restored the columns with their original types, nullability and 0 default before re-dropping them.

Hardware validation happens at the dev→main promotion, so this lands on dev without a bench-Pi run, as usual. The migration is a column drop on provably empty columns with an exact downgrade, and update.sh takes a pg_dump before migrating (#115).

Still outstanding from #123's original acceptance criterion: enforcing the drift check in CI. There is no backend CI to enforce it in — the backend has no .github/workflows, and nothing anywhere stands up Postgres. That harness needs its own issue.

[linear-code]

NEH-105

[Copilot]

Pull request overview

Advances the backend submodule to include the NEH-105 schema-hygiene changes.

Changes:

• Drops three unused collection export-tracking columns with an exact downgrade.
• Adds a local Alembic schema-drift check and migration guidance.