Fix branched Alembic migration chain

[Copilot]

Two migrations both declared down_revision = '20260220_0003', creating a fork that Alembic cannot apply linearly. 20260331_0005 also skipped 20260315_0004 entirely.

Before (broken):

0003 ──┬── 20260306_0004 (add_image_groups)
       └── 20260315_0004 (add_annotations_collections_audit)  ← orphaned branch
20260331_0005 down_revision → 20260306_0004  ← skips audit migration

After (linear):

0003 → 20260306_0004 → 20260315_0004 → 20260331_0005

Changes:

• 20260315_0004_add_annotations_collections_audit.py: down_revision '20260220_0003' → '20260306_0004'
• 20260331_0005_add_project_archive.py: down_revision '20260306_0004' → '20260315_0004'

[Copilot]

Pull request overview

This PR fixes a branched Alembic migration graph by re-pointing down_revision values so the backend schema migrations apply in a single linear order (avoiding multiple-head/fork issues during alembic upgrade head).

Changes:

• Update 20260315_0004 to depend on 20260306_0004 (instead of 20260220_0003).
• Update 20260331_0005 to depend on 20260315_0004 (instead of 20260306_0004).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
backend/alembic/versions/20260315_0004_add_annotations_collections_audit.py	Re-parents the audit/annotations migration so it no longer creates a fork off 0003.
backend/alembic/versions/20260331_0005_add_project_archive.py	Re-parents the project-archive migration so it no longer skips the audit/annotations migration.

[Copilot]

The module docstring still says Revises: 20260306_0004, but down_revision is now 20260315_0004. Please update the docstring header so it matches the actual Alembic dependency chain (helps when reading alembic history --verbose).

[Copilot]

The module docstring header still says Revises: 20260220_0003, but down_revision is now 20260306_0004. Please update the docstring so it reflects the true parent revision (otherwise migration history output and manual audits are confusing).

[Copilot]

This PR modifies down_revision of existing migrations. The repo docs explicitly call out “Never modify applied migrations” and suggest resolving conflicts via a merge revision (alembic merge heads). If these revisions may already be applied in any shared/staging/prod database, consider using a merge migration (or a new follow-up revision) instead of rewriting history, or at least document the required recovery steps (e.g., stamping/merging) for environments already upgraded.

Suggested change

	down_revision = '20260306_0004'
	down_revision = '20260220_0003'