Proposal: per-task shell/interpreter selection (bash/zsh/pwsh/node) + explicit script mode

Problem

Vite Tasks currently tries to parse commands statically (e.g. && lists) and otherwise falls back to running a shell (/bin/sh -c on Unix or cmd.exe /c on Windows).
However, many real-world tasks need:

• PowerShell on Windows,
• bash-specific features on Unix (vs /bin/sh),
• or explicit “always run as script” mode (never try to split/parse).

Not being able to choose the interpreter makes scripts less portable and pushes authors to wrap everything manually.

Evidence (primary)

• Plan has a hard-coded fallback to /bin/sh -c or cmd.exe /c.

Refs:

• https://github.com/voidzero-dev/vite-task/blob/main/crates/vite_task_plan/src/plan.rs
• PR showing shell-arg handling: https://github.com/voidzero-dev/vite-task/pull/100

Proposed behavior (Unspecified syntax)

Add an optional per-task configuration, e.g.:

• shell: "bash -c" or shell: ["powershell.exe","-NoLogo","-Command"]
  and/or an execution mode:
• mode: "auto" (current behavior),
• mode: "shell" (always run as script via chosen shell),
• mode: "spawn" (strict direct spawn; fail if not representable)

Use cases

• Windows repos standardizing on PowerShell scripts
• bash-only constructs (process substitution, arrays, [[ ... ]], etc.)
• Avoiding accidental fallback when a task should be strictly spawnable

Backward compatibility

• Default remains current behavior (auto).
• Opt-in only changes behavior for tasks that specify shell/mode.

Minimal implementation suggestion (MVP)

• Implement shell override for the existing fallback pipeline first:
  if shell is set, run the task command as one script in that shell (no splitting).
• Later iterations can decide whether/how to combine with && splitting and caching.

Start with crates/vite_task_plan/src/plan.rs and PR #100 to understand the existing fallback and shell-argument handling. The MVP is complete when an optional per-task shell runs the command as one script while preserving the default behavior; the syntax and interaction with other modes still need design decisions.