Consider persisted summary fields for scalable pipeline and flow admin lists

[chubes4]

Problem

The Pipelines admin UI derives multiple list-display fields from full pipeline/flow/job/config state at request time. At scale, this creates repeated work for common admin page loads.

Potential derived fields include:

• pipeline flow_count
• flow step_count
• flow last_run_status
• flow last_run_at
• flow next_run_at

Some values are already batched, but the page still has to assemble list metadata from multiple sources for every load.

Evidence

Homeboy profile run: bcdca196-64dd-4be2-9550-5741e64cf1c4

Related issues:

• Lightweight flows REST output mode
• Avoid full flow enrichment for collapsed cards
• Avoid selecting/decoding flow_config for list views

Proposed Direction

Evaluate whether selected summary fields should be persisted and updated at mutation/job boundaries instead of recomputed on every admin list render.

This should be treated as a design/performance follow-up, not a first patch. The immediate fix should still be lighter REST payloads and scoped loading.

Acceptance Criteria

• Document which fields are cheap enough to derive and which should be persisted.
• If persisted fields are adopted, define update points and migration/backfill behavior.
• Avoid correctness drift between derived summaries and source-of-truth config/job tables.