feat: halt pipeline step progression on error by default

[bfarmer67]

Summary

Pipelines now halt step progression on error by default. When any step — including a composed command whose inner Build() catches the exception — fails, the pipeline stops instead of feeding default data into subsequent steps (a downstream consumer failure mode).

The outermost boundary is unchanged: it still returns a result and does not throw (Roslyn EmitResult+Diagnostics model). The failure surfaces via context.IsError / context.Exception.

Implements ADR-0001 (docs/decisions/0001-pipelines-halt-on-error-by-default.md) and supersedes the rejected pipeline-error.md draft (whose premise — ExecuteAsync isolated-context swallowing — was false for this codebase; composition uses shared-context command.PipelineFunction).

Approach (Strategy B — minimal)

Build() / BuildAsProcedure() catch blocks call context.CancelAfter() on a caught exception when the new HaltOnError policy is enabled, reusing the existing cancellation short-circuit in Binder.ProcessPipelineAsync. Zero binder changes.

Backward compatibility

New behavior is the default. Existing users restore the prior run-through behavior with one wire-up option, no code changes:

services.AddPipeline( c => c.HaltOnError = false );

Changes

• New PipelineOptions { HaltOnError = true }; both AddPipeline overloads accept Action<PipelineOptions> configure = null
• IPipelineContext.HaltOnError (peer of Throws), propagated through the clone constructor so WaitAll forks inherit it
• PipelineContextFactory carries/stamps the option; CreateFactory gains an optional trailing PipelineOptions (positional callers unchanged)
• Docs: command-pattern.md (boundary-model section + corrected composition note), dependency-injection.md (Pipeline Options)

Verification

• 255/255 tests green across all 6 projects (net10.0); 18 new halt-on-error tests covering direct/nested/conditional/selector composition, ForEach, WaitAll fork isolation + reducer propagation, value-type defaults, Throws rethrow, and the programmatic-vs-thrown trigger boundary
• dotnet build -warnaserror clean

Notes / API surface

• IPipelineContext gaining HaltOnError is a breaking change for external custom IPipelineContext implementers (none in-repo) — flag in release notes
• An errored pipeline also reports IsCanceled == true (halt reuses cancel-after); IsError distinguishes the two — consistent with how validation failures already behave
• No CHANGELOG file in repo (nbgv / GitHub Releases); release note deferred to the release process