[TE-6274] Fall bktec plan fallback parallelism back to BUILDKITE_PARALLEL_JOB_COUNT

[gchan]

Description

Fall the bktec plan fallback parallelism back to the static
BUILDKITE_PARALLEL_JOB_COUNT (cfg.Parallelism) when --max-parallelism
(BUILDKITE_TEST_ENGINE_MAX_PARALLELISM) is unset, so an unavailable Test Engine
degrades to "runs the full suite un-optimised" instead of "silently runs nothing".

When the API is unreachable or returns an error plan, bktec plan substitutes a
local fallback and exits 0. The fallback took cfg.MaxParallelism verbatim, so an
unset --max-parallelism gave parallelism 0: --pipeline-upload uploaded nothing,
--json emitted "0", and the suite was skipped. A green build that tested
nothing is the dangerous shape; "runs un-optimised" (non-zero parallelism) is the
acceptable fail-open degradation bktec run already makes.

This resolves the fallback parallelism like bktec run does —
MaxParallelism → Parallelism → 0 — aligning the two commands. It only adds
runs where there were none, so plans with a non-zero parallelism are unchanged.
The --max-parallelism help text already promises "when 0 ... the test plan
parallelism will be derived from BUILDKITE_PARALLEL_JOB_COUNT"; this honours that
in the fallback path.

Residual both-unset gap: when both --max-parallelism and
BUILDKITE_PARALLEL_JOB_COUNT are 0 (e.g. off-agent plan --plan-identifier), the
fallback would still be parallelism 0. #578 (TE-6275, merged) now catches this up
front with a client-side parallelism > 0 check that rejects the config before any
network call, so it no longer reaches this fallback.

Context

TE-6274. Surfaced during review of TE-6254 (bktec plan --plan-out, merged);
independent of it. Companion to #578 (TE-6275), the client-side parallelism > 0
check.

Changes

• Add fallbackParallelism(cfg) and wire it into makeFallbackPlan and the
  --plan-out emitLocalFallback path in internal/command/plan.go.

Testing

Backed by specs: --pipeline-upload and --plan-out cases assert the fallback
uses the static parallelism when --max-parallelism is unset. Since #578 landed on
main, the parallelism-0 guard test drives Plan()'s guard directly (ValidateForPlan
now rejects the both-unset config before it reaches the guard; the guard stays as
defence in depth). AI assisted.

[buildsworth-bk-app]

I didn't find any code issues in this pass. This reads as an L1 bug fix with focused fallback-path coverage; I'm leaving a comment rather than an approval because the PR is still marked draft.

Want to dig deeper? The full session log is attached to this Buildkite build. Download the session file and open a new pi session with it:

Download the buildsworth logs from build 2452, then answer my questions about the findings.

[buildsworth-bk-app]

Focused fallback-path bug fix: the local fallback now derives parallelism from --max-parallelism or BUILDKITE_PARALLEL_JOB_COUNT, with direct coverage for both --pipeline-upload and --plan-out. I read this as L1: no API contract or config surface change, and CI is green.

Want to dig deeper? The full session log is attached to this Buildkite build. Download the session file and open a new pi session with it:

Download the buildsworth logs from build 2468, then answer my questions about the findings.

[buildsworth-bk-app]

Bug fix with focused fallback-path coverage; no API surface or configuration contract change. I read this as L1 because it only changes the local fallback parallelism resolution from zero to the existing static job count when max-parallelism is unset.

Want to dig deeper? The full session log is attached to this Buildkite build. Download the session file and open a new pi session with it:

Download the buildsworth logs from build 2469, then answer my questions about the findings.