Epic: Introduce a Database Backing the Catalog Pipeline

so here is a thing i think we should at least be talking about soonish

## Problem

The app currently relies entirely on large JSON artifacts built offline (catalog/output, catalog/ga2/output). As the data grows and relationships get richer, JSON-only storage and simple Python scripts are creating fragility:
- External IDs can change upstream; JSON snapshots get stale without lineage tracking.
- Relationships (workflows ↔ assemblies ↔ organisms ↔ read runs) are loosely defined across multiple files.
- Read-run counts follow different generation rules than the rest of the catalog.
- Some data is shared between BRC and GA2, some is site-specific.
- Build scripts are long-running and monolithic; no modular pipeline to rebuild small slices.
- Filtering logic (workflow compatibility) is duplicated: in the build, in workflow page, and in assembly detail pages.
- API “filters” loop through JSON arrays, which doesn’t scale as entity counts grow.

## Why Now

Upcoming features will stress the current pipeline:
- Ingesting real SRA metadata that needs search/filter + relationships to existing assemblies.
- New “genes” entity with many-to-many relationships to assemblies/organisms (orders of magnitude more rows).
- Different “support levels” for assemblies (FASTA only vs. indexes) requiring contextual display rules.
- Large influx of assemblies → table/filter performance concerns.
- User accounts with saved entities or custom submissions (“my assemblies”, “add organism by taxon ID”) will need stable identifiers and referential integrity.
- The JSON build will only get longer and harder to reason about; moving to a DB/API unlocks incremental updates, validations, and eventual automation.

## Goals

1. Design a persistent catalog store (e.g., Postgres) that models workflows, assemblies, organisms, read runs, genes, etc., with clear foreign keys.
2. Define ETL pipeline to populate/refresh the DB from upstream sources with modular steps and reproducible logging.
3. Expose data through an API consumed by the Next.js app instead of reading JSON bundles.
4. Consolidate filtering/compatibility logic so it runs once in the DB/ETL layer; clients get precomputed relationships.
5. Support site-specific catalogs (BRC vs. GA2) via filters/views in the DB, not separate JSON directories.
6. Lay groundwork for user-associated data (saved assemblies, custom organisms) stored alongside catalog objects.

## Related context

Earlier issues that framed parts of this problem, collected here for context:

- #499 — make our data less fluid (stable IDs vs. upstream churn)
- #1047 — external identifier drift, data provenance, API snapshot clarity
- #1049 — coordinated ingestion & internal consistency across related data
- #1189 — consolidate workflow filtering logic between build and runtime
- #493 — annotation status on assemblies sometimes blank (data quality)
- #690 — remove GTF URLs from catalog JSON (export shape)
- #1336 — ingest `assembly_name` / normalize `"None"` strings (data quality)

## Pre-work / requirements decisions

Decisions to settle as prerequisites for the DB design:

- #595 — automatically pull in all assemblies for an NCBI tax id (ingest behavior)
- #647 — update taxonomic groups (taxonomy data)