refactor[next]: replace workflow combinators with explicit typed pipelines

The workflow-combinator framework introduced by ADR 0011 had grown to a dozen
abstractions to express what is, in the end, function composition. Measured
against actual use, only `CachedStep` was a deep module; the rest were shallow
wrappers around `Callable[[S], T]`, and the reflection loop in
`NamedStepSequence.__call__` was `Any`-typed, defeating the static typing
ADR 0011 prized.

The named pipelines become plain frozen dataclasses with an explicit, fully
typed `__call__`:

- `backend.Transforms` keeps its input-dependent step *selection* -- the `match`
  that used to live in `step_order` now lives in `__call__`, where the order is
  literally readable -- and the `step_order` method is retained only to raise,
  so a downstream override fails loudly instead of being silently ignored.
- `recipes.OTFCompileWorkflow` becomes `backend.CompilePipeline` and spells out
  its three steps; `otf.recipes` and `otf.toolchain` are deleted.
- Both take over emitting the `stage_hook` added in the previous PR. Names,
  order, count and artifacts are unchanged; the two instrumentation tests that
  assert the exact stage sequences pass unmodified, which is the proof.

Steps are now plain callables, named by the `workflow.Step[S, T]` alias, and
customization stays composition-time via `dataclasses.replace`. Deleted:
`Workflow`, `ChainableWorkflowMixin`, `ReplaceEnabledWorkflowMixin`,
`NamedStepSequence`, `MultiWorkflow`, `StepSequence`, `make_step`, `.chain`,
the three adapters in `otf.toolchain`, and the five `adapted_*_factory`
wrappers whose only job was to wrap a function into an adapter. `CachedStep`'s
body is unchanged; it loses only the mixin bases, and with them `.replace` and
`.chain`.

Because steps no longer need to be adapter objects, the seven ffront factories
collapse to returning either the bare function or a `CachedStep` around it, and
the three per-step callers in `decorator.py` lose their wrap/unwrap dance.

What ADR 0011's decisions become: named steps with a visible order are now
dataclass fields plus an explicit `__call__`; statically typed composition is
checked end-to-end instead of through an `Any`-typed reflection loop;
customization at composition time is `dataclasses.replace`; and steps still
compose across backends because every existing step already satisfies
`Step[S, T]`.

No behavior change, and -- unlike the naming PR -- no persistent cache key
rotates: fingerprints embed a class's qualified name and fields but never its
bases, and neither renamed pipeline is reachable from a persistent cache's
fingerprint graph.

Breaking, with no compatibility aliases: the deleted combinators and the
`otf.recipes` / `otf.toolchain` modules, `.replace()` / `.chain()` on the
classes that kept them via the mixins, overriding `Transforms.step_order`,
`roundtrip.foast_to_gtir_step` (now a data-only step), and
`linter_factory(adapter=...)` (the parameter was accepted and ignored).

Claude-Session: https://claude.ai/code/session_01R8zRtFMhdJ8c96XJYCXkRk

Author: egparedes

docs/development/ADRs/next/0029-Toolchain-Naming-and-Pipeline-Simplification.md

@@ -109,7 +109,7 @@ Named pipelines become frozen dataclasses with an explicit, fully typed
 customization stays composition-time via `dataclasses.replace`. The
 combinator framework (both mixins, `NamedStepSequence`, `MultiWorkflow`,
 `StepSequence`, `make_step`, `.chain`, the three adapters) is deleted;
-`CachedStep` is kept unchanged.
+`CachedStep` is kept, minus the mixin-provided `.replace` / `.chain`.
 
 What ADR 0011's decisions become:
 
@@ -135,16 +135,16 @@ needing a variant step builds a variant pipeline with `dataclasses.replace`.
 
 ### Phasing
 
-The decisions in this ADR land as a stack of PRs. The naming decisions above
-land first, except the `OTFCompileWorkflow` → `CompilePipeline` rename, which
-lands with the pipeline PR; the "Pipeline, not combinators" and "Stage
-observability" decisions are implemented in follow-up PRs of the same stack.
+The decisions in this ADR landed as a stack of PRs: the naming decisions first
+(#2741), then stage observability (#2742), then the pipeline simplification
+together with the deferred `OTFCompileWorkflow` → `CompilePipeline` rename
+(this stack's final PR).
 
 ## Consequences
 
 - The dace `__sdfg__` reach-in (duck-typing through `executor.translation`
-  and mutating frozen stages) will be replaced by a dace-owned translate-only
-  step built with `dataclasses.replace`.
+  and mutating frozen stages) was replaced by a dace-owned translate-only
+  toolchain built with `dataclasses.replace`.
 - Downstream code subclassing the deleted combinators or overriding
   `Transforms.step_order` must migrate to explicit `__call__` composition.
 - Downstream code must migrate to the new names in the same release: the old

docs/user/next/advanced/HackTheToolchain.md

@@ -4,51 +4,36 @@ import typing
 
 from gt4py import next as gtx
 from gt4py.next.otf import workflow
-from gt4py.next.ffront import field_operator_ast as foast, stages as ff_stages
-from gt4py import eve
 ```
 
 <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet"><script src="https://spcl.github.io/dace/webclient2/dist/sdfv.js"></script>
 <link href="https://spcl.github.io/dace/webclient2/sdfv.css" rel="stylesheet">
 
 ## Replace Steps
 
-```python
-cached_lowering_toolchain = gtx.backend.DEFAULT_TRANSFORMS.replace(
-    past_to_itir=gtx.ffront.past_to_itir.past_to_gtir_factory(cached=False)
-)
-```
-
-## Skip Steps / Change Order
+Pipelines are frozen dataclasses whose fields are the steps, so a variant is built with `dataclasses.replace`.
 
 ```python
-DUMMY_FOP = workflow.ProgramWithArgs(
-    definition=ff_stages.DSLFieldOperatorDef(definition=None), args=None
+cached_lowering_toolchain = dataclasses.replace(
+    gtx.backend.DEFAULT_TRANSFORMS,
+    past_to_itir=gtx.ffront.past_to_itir.past_to_gtir_factory(cached=False),
 )
 ```
 
-```python
-gtx.backend.DEFAULT_TRANSFORMS.step_order(DUMMY_FOP)
-```
-
-```python
-@dataclasses.dataclass(frozen=True)
-class SkipLinting(gtx.backend.Transforms):
-    def step_order(self, inp):
-        order = super().step_order(inp)
-        if "past_lint" in order:
-            order.remove("past_lint")  # not running "past_lint"
-        return order
+## Skip Steps
 
+Which steps run is decided by `Transforms.__call__` from the type of the input definition; that selection is not configurable. Behavior is customized by replacing a step, so skipping one means replacing it with an identity step.
 
-same_steps = dataclasses.asdict(gtx.backend.DEFAULT_TRANSFORMS)
-skip_linting_transforms = SkipLinting(**same_steps)
-skip_linting_transforms.step_order(DUMMY_FOP)
+```python
+skip_linting_transforms = dataclasses.replace(
+    gtx.backend.DEFAULT_TRANSFORMS,
+    past_lint=lambda past_def: past_def,  # identity step: linting skipped
+)
 ```
 
-## Alternative Workflow
+## Alternative Pipeline
 
-Compile workflows are plain frozen dataclasses, so a variant is built by
+Compile pipelines are plain frozen dataclasses, so a variant is built by
 replacing the steps you want to change on one the builders produced.
 
 ```python
@@ -61,7 +46,7 @@ class MyCodeGen: ...
 class Cpp2BindingsGen: ...
 
 
-pure_cpp2_workflow = dataclasses.replace(
+pure_cpp2_pipeline = dataclasses.replace(
     gtx.program_processors.runners.gtfn.make_gtfn_compile_workflow(
         cmake_build_type=gtx.config.CMakeBuildType.DEBUG
     ),
@@ -70,7 +55,9 @@ pure_cpp2_workflow = dataclasses.replace(
 )
 ```
 
-## Invent new Workflow Types
+## Invent new Pipeline Types
+
+A pipeline is just a frozen dataclass of steps with an explicit, fully typed `__call__`. Nothing else is needed, so a non-linear shape is written the same way as a linear one.
 
 ```mermaid
 graph LR
@@ -89,15 +76,11 @@ OUT_T = typing.TypeVar("OUT_T")
 
 
 @dataclasses.dataclass(frozen=True)
-class FullyModularDiamond(
-    workflow.ChainableWorkflowMixin[IN_T, OUT_T],
-    workflow.ReplaceEnabledWorkflowMixin[IN_T, OUT_T],
-    typing.Protocol[IN_T, OUT_T, A_T, B_T, X_T, Y_T],
-):
-    split: workflow.Workflow[IN_T, tuple[A_T, X_T]]
-    track_a: workflow.Workflow[A_T, B_T]
-    track_x: workflow.Workflow[X_T, Y_T]
-    combine: workflow.Workflow[tuple[B_T, Y_T], OUT_T]
+class Diamond(typing.Generic[IN_T, OUT_T, A_T, B_T, X_T, Y_T]):
+    split: workflow.Step[IN_T, tuple[A_T, X_T]]
+    track_a: workflow.Step[A_T, B_T]
+    track_x: workflow.Step[X_T, Y_T]
+    combine: workflow.Step[tuple[B_T, Y_T], OUT_T]
 
     def __call__(self, inp: IN_T) -> OUT_T:
         a, x = self.split(inp)
@@ -106,20 +89,10 @@ class FullyModularDiamond(
         return self.combine((b, y))
 
 
-@dataclasses.dataclass(frozen=True)
-class PartiallyModularDiamond(
-    workflow.ChainableWorkflowMixin[IN_T, OUT_T],
-    workflow.ReplaceEnabledWorkflowMixin[IN_T, OUT_T],
-    typing.Protocol[IN_T, OUT_T, A_T, B_T, X_T, Y_T],
-):
-    track_a: workflow.Workflow[A_T, B_T]
-    track_x: workflow.Workflow[X_T, Y_T]
-
-    def split(inp: IN_T) -> tuple[A_T, X_T]: ...
-
-    def combine(b: B_T, y: Y_T) -> OUT_T: ...
-
-    def __call__(inp: IN_T) -> OUT_T:
-        a, x = self.split(inp)
-        return self.combine(b=self.track_a(a), y=self.track_x(x))
+Diamond(
+    split=lambda inp: (inp, inp),
+    track_a=lambda a: a + 1,
+    track_x=lambda x: x * 2,
+    combine=lambda by: by[0] + by[1],
+)(3)
 ```