===== FTR-CLI-CONSOLIDATE-REMOVE-STEPS — Remove ad-hoc `--steps` / `--pipeline-yaml` path from CLI

*Status:* Discarded in favor of <<FTR-CLI-STEPS-DEPRECATION-P3G#,FTR-CLI-STEPS-DEPRECATION-P3G>>
*Epic:* Phase 3b — Pipeline & Orchestration Consolidation

*Decision:*::
This proposal was rejected after reassessment of the actual architecture and user-facing tradeoff.
The ad-hoc `steps.yaml` path is the older, direct configuration form; `--config` plus
`--pipeline` is a later abstraction layered on top, not a replacement of a separate core mechanism.
Removing `--steps` would therefore not materially simplify the engine and would only modestly simplify
the CLI entry path while removing real ad-hoc functionality.

The chosen direction is to keep support for `--steps`, stop treating it as the preferred documented
entry path, and add a deprecation warning plus documentation de-emphasis instead. See
<<FTR-CLI-STEPS-DEPRECATION-P3G#,FTR-CLI-STEPS-DEPRECATION-P3G>>.

*Context:*::
The current CLI exposes multiple ways to describe execution flow:

* product-oriented shims such as `sheets-pack` / `sheets-unpack`,
* `sheets-run --config ... --pipeline <name>` for named pipelines in a maintained config file,
* the ad-hoc YAML path via `--steps` and the deprecated alias `--pipeline-yaml`.

Historically, the ad-hoc YAML path appears to be the earlier form of pipeline selection. Later, the CLI gained support for a config file containing multiple named pipelines, which repurposed the term `pipeline` for selecting one of several predefined flows. The former ad-hoc pipeline file was then renamed to `steps`, while the deprecated alias remained for compatibility.

This leaves the CLI with overlapping concepts for essentially the same execution model. The `--steps` path is especially problematic because it is not merely a list of primitive steps, but effectively another way to supply a pipeline YAML. This increases mental load, complicates documentation, and makes the public CLI surface less coherent than necessary.

At the same time, the demo repository can be migrated away from this mechanism first, so that consolidation of the core CLI can happen afterwards without blocking demo integration work.

*Goal:*::
Consolidate the CLI around two explicit usage modes only:

. *Product-oriented shims* for common user intents (`sheets-pack`, `sheets-unpack`, and future semantically clear commands).
. *Generic engine mode* via `sheets-run --config ... --pipeline <name>` for maintained, named, reusable workflows.

The ad-hoc YAML path `--steps` and its deprecated alias `--pipeline-yaml` shall be removed from the supported CLI surface after consumers in the demo repository no longer depend on them.

*Rationale:*::
* `--steps` duplicates the role of a single-pipeline config file while using different terminology.
* `--pipeline-yaml` is already deprecated and indicates historical carry-over rather than a clean long-term design.
* The combination of shims plus named pipelines is sufficient for both common interactive use and maintained repository workflows.
* Removing the ad-hoc YAML path reduces ambiguity about what the canonical execution model is.
* The product surface becomes easier to explain: either use a semantic shim, or use `run` with a maintained config and a named pipeline.

*Non-Goals:*::
* No removal of the underlying pipeline engine or step factory mechanism.
* No restriction of plugin support via dotted-path step factories inside maintained pipeline configs.
* No forced redesign of the demo repository in the same change set; demo migration is a prerequisite, not part of this feature itself.
* No removal of `profile` support in this feature unless incidental simplifications become trivial and non-breaking.

*Solution:*::
. Remove the public `--steps` option from `sheets-run`.
. Remove the deprecated alias `--pipeline-yaml` from `sheets-run`.
. Remove helper code paths that interpret inline config from a steps YAML file.
. Keep one generic configuration path only:
.. load config from `--config`
.. optionally select pipeline via `--pipeline`
.. optionally select IO defaults via `--profile`
.. allow CLI IO overrides to continue winning over config defaults
. Keep and document shims as the preferred product-facing entrypoints for common tasks.
. Adjust tests so that CLI delegation and end-to-end coverage no longer assume the existence of `--steps` / `--pipeline-yaml`.
. Update help text and documentation to describe the reduced model clearly.

*Migration Strategy:*::
. First migrate the demo repository so that it no longer invokes `sheets-run` via `--steps` / `--pipeline-yaml`.
. Then remove support in the core CLI.
. If desired, one intermediate release may keep a hidden compatibility alias that fails fast with a clear migration message instead of silently supporting the old path.

*Acceptance:*::
* `sheets-run` no longer accepts `--steps`.
* `sheets-run` no longer accepts `--pipeline-yaml`.
* The only supported generic pipeline selection mechanism is `--config` plus optional `--pipeline`.
* Product-oriented shims continue to work and remain the preferred user-facing CLI for common workflows.
* Demo repository integration works without any use of `--steps` / `--pipeline-yaml`.
* Existing tests are updated so that no passing test depends on the removed ad-hoc YAML path.
* CLI help output and documentation no longer mention the removed options except, if applicable, in an explicit migration note.

*Follow-up Considerations:*::
* After this consolidation, reassess whether `profile` should remain allowed to supply a default pipeline name or whether it should be narrowed to IO defaults only.
* After the removal, future CLI extensions should prefer either a semantic shim or a named pipeline in config, rather than introducing another parallel execution-specification mechanism.
