Add first-class preflight validation to publish and deploy pipelines

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Pipeline validation steps currently participate in the same dependency DAG as work that can produce artifacts or mutate deployment state. A validation step that is required by `publish`, `deploy`, or their prerequisite steps only blocks steps that explicitly depend on it. Independent sibling steps feeding the same aggregation sink can begin concurrently and perform side effects before validation fails.

PR #19190 demonstrates this gap. `DotnetProjectResource` cannot be published automatically and should fail before any publish or deploy work starts. The current pipeline model has no first-class way to express that requirement, so the PR needs resource-specific graph traversal to add validation dependencies to every publish/deploy participant while avoiding steps shared with the `before-start` graph.

The same risk applies to future validation steps and to existing publishers that do not explicitly depend on `publish-prereq` or `deploy-prereq`.

### Describe the solution you'd like

Introduce a first-class preflight/validation concept in the pipeline core.

After resolving and filtering the selected pipeline graph, the pipeline should execute all applicable preflight validations before scheduling any side-effecting actions for that operation. A failed validation should:

- prevent every selected publish/deploy action from starting, including independent sibling steps;
- flow through the existing pipeline activity reporter and preserve actionable error reporting;
- apply only to the relevant operation, without leaking publish validation into Run mode or the `before-start` graph;
- work consistently for steps expressed with either `DependsOnSteps` or `RequiredBySteps`, including custom integration steps;
- remain visible in pipeline diagnostics and step-listing surfaces.

The API could use a dedicated step phase, capability, or well-known tag. An alternative is for pipeline core to enforce `publish-prereq`/`deploy-prereq` ordering automatically for every participant, but that still needs well-defined behavior for transitive and shared dependencies. A reusable graph-query helper alone would reduce duplication without guaranteeing execution ordering.

Existing validation steps, including build-only container validation and JavaScript publish validation, should be evaluated for migration to the new mechanism. Coverage should include a sibling step that only feeds the publish/deploy aggregation sink and a step shared with `before-start`.

### Additional context

- Example scenario and current workaround: #19190
- The closest existing graph helper is `DistributedApplicationPipeline.ComputeTransitiveDependencies`, which runs after `RequiredBySteps` normalization.
- `PipelineConfigurationContext` currently supports lookups by tag or resource but does not provide an operation-aware preflight abstraction.

Start with PR #19190, DistributedApplicationPipeline.ComputeTransitiveDependencies, and PipelineConfigurationContext to understand current graph normalization and lookups. Trace publish, deploy, Run, and before-start graph selection, then define coverage for sibling steps, shared steps, both dependency directions, reporting, diagnostics, and step listing. Done means validation blocks every applicable side-effecting action without affecting unrelated operations.

Written by the indexing model from the issue text.