Add a Bash runner alongside the PowerShell and Terraform runners

Goal

Add a fourth runner alongside Dorc.Runner, Dorc.NetFramework.Runner, and Dorc.TerraformRunner: Dorc.BashRunner, executing bash scripts as part of a deployment request.

(The original title said "monitor"; the existing terminology calls these "runners". The orchestrator is the Monitor service which dispatches to runners. This issue is about the runner, not the Monitor.)

Why

• Linux deploy targets and cross-platform automation flows that the PowerShell runners can't cleanly host.
• Direct unblocker for #361 (argoCD scripts — the argoCD CLI is bash-shaped).
• Cross-platform tooling (kubectl, helm, aws, gcloud) is already shell-first; wrapping every invocation in PowerShell adds friction.

Scope

1. New project Dorc.BashRunner modelled on Dorc.TerraformRunner (separate exe, started by Monitor's ScriptDispatcher via RunnerProcessStarter).
2. Script-type discrimination: introduce a ScriptType field (or equivalent) on the script model and dispatch on it, rather than further overloading PowerShellVersionNumber. Existing PS5.1 / PS7+ / Terraform collapse cleanly into the new enum.
3. appsettings.json: new BashDeploymentRunnerPath setting + <Json:JsonFile> entry in WiX NonProdActionService.wxs / ProdActionService.wxs.
4. WiX Setup.Dorc.wixproj harvest of the new runner directory + HeatTransform.xslt File-Id rewrite (per the same pattern that bit us in #584's MSI-install fix).
5. Bash-runner executable choice: bundle Git-for-Windows' bash.exe (as git-bash) or rely on a system-installed bash / WSL — pick one with a stated rationale; default recommendation is bundled git-bash for environment parity.
6. Logging contract identical to existing runners (pipe-based) so the Monitor's log capture is unchanged.
7. Security context: runs under the same Windows credentials as PS runners, via the existing securityContext. No new credential surface.
8. UI surface: the script-creation page must offer the new script type in its dropdown; existing PS-only UI must not regress.

Acceptance criteria

• A1. A script created with ScriptType = Bash and a non-empty .sh file dispatches to Dorc.BashRunner and executes; stdout/stderr appear in the request log via the existing pipe.
• A2. A script's exit code maps to request status the same way existing runners do (0 = success, non-zero = failure, terminated-process sentinel = cancelled).
• A3. A multi-component request that mixes Bash + PS components dispatches each component to the correct runner; group construction in GetScriptsGroupedByPowerShellVersion (or its replacement after the rename) groups contiguous components by script type, mirroring current PS-version grouping.
• A4. Dorc.BashRunner.exe is installed by Setup.Dorc.msi and its path written into appsettings.json by the WiX <Json:JsonFile> configuration. Validated by the existing install-success criteria check.
• A5. Cancellation: a running bash script can be cancelled by the Monitor through the existing process.Kill() path; the runner must propagate SIGTERM to the bash subprocess so the script ends quickly.
• A6. Existing PS5.1 / PS7+ / Terraform deployments continue to work unchanged. Regression test: run a representative set of existing scripts on the changed build with no observable difference.
• A7. The script-type field is migrated for existing scripts (default to current PowerShellVersionNumber mapping) so no manual data fixup is required at deploy time.
• A8. Documentation in docs/ covers: how a script author writes a bash script, what the runtime environment is (which bash, which PATH, which env vars are set), and the runner's working-directory convention.

Non-goals

• WSL-as-target (running bash on a remote Linux box) — that's a different feature, separate planning.
• Linux-native build of any DOrc component.
• Native Linux deployment targets in the existing infrastructure model.

Risks / unknowns

• Bundling Git-for-Windows adds ~50 MB to the MSI footprint. Confirm with stakeholders before committing.
• Bash subprocess kill semantics on Windows (signal vs job-object) need a small spike to validate A5.
• Script-type field rename touches the OpenAPI surface; consumers (Tools.RequestCLI, dorc-web) need updating in lock-step. Plan as one HLPS step.

Process note

Per this repo's conventions (CLAUDE.md), substantive change of this size warrants HLPS → IS → JIT spec rather than a direct PR. This issue should be the input to that planning cycle, not the implementation tracker.

Start with CLAUDE.md and the existing Dorc.TerraformRunner, ScriptDispatcher, and RunnerProcessStarter flow. Trace the script model, GetScriptsGroupedByPowerShellVersion, appsettings.json, NonProdActionService.wxs, ProdActionService.wxs, Setup.Dorc.wixproj, and HeatTransform.xslt, then review the script-creation UI and OpenAPI consumers. Done means a documented HLPS → IS → JIT plan covers dispatch, migration, cancellation, packaging, UI, regression checks, and runtime documentation.