Consolidate workflow filtering logic between build and runtime

## Problem

We currently evaluate workflow→assembly compatibility in three places:
1. Catalog build (catalog/build/ts/build-workflow-mappings.ts) – generates counts per workflow.
2. Workflows page (app/views/WorkflowsView/utils.ts) – filters workflows again client-side, even though counts already exist.
3. Assembly detail pages (app/components/Entity/components/AnalysisMethodsCatalog/utils.ts) – re-run essentially the same compatibility logic per assembly.

This duplication means every site build and page render recomputes very similar filters, and the logic has to stay in sync across three implementations.

## Why it matters

- Higher chance of drift/bugs when compatibility rules change.
- Extra compute on the client (esp. BRC with larger catalogs).
- Harder to evolve toward richer compatibility data or a future DB/API without a single source of truth.

## Proposal

Explore consolidating filtering so it runs once and downstream code consumes the precomputed result. Options to evaluate:

1. Shared filtering/mapping module – single TS utility used by both build script and app (requires reconciling generic vs concrete types).
2. Precompute & ship richer mappings – build step outputs final workflow lists per assembly/workflow so the app doesn’t re-filter.
3. Future DB/API – if we expect a DB soon, consider deferring to a query-driven approach.

The goal is to pick a path that avoids re-implementing the same logic in multiple layers and makes future compatibility changes safer.