summarize-nextflow: derived subworkflow-level edge view

## Summary

Today `summarize-nextflow` emits a flat process-tier `workflow.edges[]` (155 edges over 123 processes for sarek). Consumers wanting a subworkflow-tier view must walk the call graph by hand. Issue #211 (or rather, the just-merged `processes[].in_subworkflows[]`) gives a cheap denormalized FK that lets a consumer `groupBy` on the client side, which solves ~80% of the use case. This issue tracks the deeper fix when that proves insufficient.

## Two layered options

### Option (a) — derived subworkflow-level edges

Emit two new fields:

- `subworkflows[].edges[]` — same shape as `workflow.edges[]`. Either internal (both endpoints in this subworkflow's `calls[]`) or boundary (`from`/`to` references the subworkflow's `inputs[]` / `outputs[]` ports).
- `workflow.subworkflow_edges[]` — edges between subworkflows. One row per cross-subworkflow flow, with `evidence: string[]` listing the underlying process-edge `(from, to)` pairs that justify it.

Roughly 1 cross-subworkflow edge ≈ 5–20 process-level edges. For sarek the ~74 subworkflows would collapse to ~30 cross-subworkflow edges, an order of magnitude more readable.

### Option (b) — typed channel routing

Track `subworkflows[].inputs[]` / `outputs[]` as typed ports (already partially present), and rewrite all edges in terms of those ports. Process-level edges live only inside subworkflow bodies. Closer to CWL's nesting model.

Big refactor (touches operator-chain reconciliation, channel inference, every consumer). Big payoff for downstream Molds that want to operate at the subworkflow tier without re-deriving topology.

## Recommendation

Don't ship either now. Keep the `processes[].in_subworkflows[]` denormalization (#TODO) and let consumers `groupBy`. Reach for (a) when a second sarek-class pipeline confirms client-side grouping isn't enough — or when the data-flow Mold's eval cases demand subworkflow-level edge testing. Defer (b) indefinitely.

## Boundary concern

(a) and (b) drift from "summarize what's in the source tree" toward "infer a clean DAG", which is exactly the boundary the source-summary Molds were designed to keep on the *target-shaping* side. Any derived edge view in `summarize-nextflow` shifts work upstream of where the source/target Molds expect it. Worth keeping in mind: derived fields earn their keep only if every consumer agrees on the derivation rule.

## Trigger

Reopen / promote out of `priority/v2` when one of:

- The data-flow Mold's eval cases need subworkflow-level structural assertions.
- A second sarek-class fixture (taxprofiler? sentieon?) reproduces the "process-tier DAG too dense to consume" finding.
- A new consumer Mold (e.g. a CWL→Galaxy template Mold) lands that needs subworkflow-tier abstraction natively.

## Context

- Current workaround: `processes[].in_subworkflows[]` (denormalized FK; shipped alongside this issue).
- Refinement journal: `content/molds/summarize-nextflow/refinements/2026-05-08-sarek-emulation.md`.
- Sarek summary fixture: `casts/claude/skills/_emulated-runs/nf-core-sarek/summary.json`.