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

[egparedes]

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].

Because dataclasses.replace is now the customization route, a pipeline can
be assembled without a builder, so the builders' check_device_agreement no
longer sees every route. CompilePipeline and Toolchain therefore check
device agreement themselves, in __post_init__, which dataclasses.replace
re-runs:

• CompilePipeline: all steps that declare a device (DeviceConfigurable,
  looking through CachedStep) must declare the same one, exposed as
  CompilePipeline.device_type.
• Toolchain: the allocator's __gt_device_type__ must match the device the
  backend declares.

Like the builder check, these only check and never mutate. They only see
components that declare a device, so a custom step without device_type is
not checked. HackTheToolchain.md and WorkflowPatterns.md now say so, and also
that a step passed to dataclasses.replace is used as given: replacing
translation also replaces its CachedStep, unlike passing a step builder.
ADR 0029 records the rule.

The type: ignore in make_gtfn_bindings from #2808 is gone, but not because
the typing was fixed: the CompilePipeline fields use unparameterized
ProgramSource / ExtensionSource, so mypy accepts ExtensionGenerator there,
and it would also accept a pipeline mixing C++ and SDFG steps. Parameterizing
CompilePipeline over the code spec only helps once the builders return
parameterized pipelines. That is left to a follow-up, recorded in ADR 0029.

The one behavior change is that a pipeline or toolchain whose components
declare different devices now raises ValueError at construction; the
pre-built toolchains are unaffected.

Unlike the naming PR, no persistent cache key rotates: fingerprints embed a
class's qualified name and fields but never its bases, neither pipeline is
reachable from a persistent cache's fingerprint graph, and the device checks
add no fields.

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).

[egparedes]

Following the review of #2808, its builder-level device check (check_device_agreement) was removed: default and partially customized steps are in sync by construction, and a fully custom step builder is the caller's responsibility. The construction-time checks in this PR (CompilePipeline.__post_init__ and Toolchain.__post_init__) now define the DeviceConfigurable protocol themselves in backend.py.

@tehrengruber, the same "where do consistency checks end" question applies to these, so this is the place to decide whether they stay: they are the only checks that also cover dataclasses.replace and direct construction, and removing them is a self-contained change to this PR.