IR transform stages between compile and generate

## Context

The out-directory design (`docs/superpowers/specs/2026-09-02-out-directory-design.md`, branch `t3code/understand-compile-output`) reserves room for transformation stages between compile and generate, in the style of a unified.js pipeline (parse, transform plugins, stringify). Task ids are path-like (`compile`, `transform/`, `generate/`), each task writes a result record with an `inputs` provenance list and an `ir` storage descriptor, and one function, `resolve_ir_task`, decides which task's IR generate consumes. Today that function always returns `compile`.

## What this issue covers

- `[pipeline].transforms = ["...", "..."]` in `morphir.toml`, an ordered list of transform names.
- `resolve_ir_task` reads the list and returns `transform/` when it is non-empty.
- A real `morphir transform` command (the current one is a stub) that runs one named transform: read the upstream task's IR through its descriptor, write the result to `transform/.dest/`, and write a record with `inputs` and `ir`.
- A transform extension protocol so transforms can be shipped as extensions, mirroring the frontend and backend provider protocols.
- Storage may change between stages (for example JSON in, YAML out) because each record declares its own `ir` descriptor.

## Out of scope

Incremental execution and `inputsHash` are tracked separately.

Start with docs/superpowers/specs/2026-09-02-out-directory-design.md, then trace resolve_ir_task and the current morphir transform stub. Verify the transforms list is read from morphir.toml, named stages consume and record IR through descriptors, and the extension protocol matches the existing provider protocols; done means the configured pipeline resolves and runs transforms with provenance records.

Written by the indexing model from the issue text.