Copilot CLI 1.0.83 (gh-aw v0.89.x): specific models now fail with persistent, zero-token http_400_response_error

## Summary

After upgrading from gh-aw v0.88.7 to v0.89.13 (Copilot CLI bundled version 1.0.80 → 1.0.83), workflows that previously ran successfully with `engine.model: gpt-5.6-luna` or `gpt-5.6-sol` now fail deterministically on every run with a non-retryable `400 Bad Request`, immediately and with zero tokens produced.

## Environment

- gh-aw: v0.88.7 (working) vs v0.89.13 (failing)
- Copilot CLI: 1.0.80 (working) vs 1.0.83 (failing)
- Engine: `copilot`
- Models affected (confirmed, both fail identically): `gpt-5.6-luna`, `gpt-5.6-sol`

## Reproduction

Two independently upgraded workflows (different repos, each defaulting to one of the two models above) both began failing on every run after the bump, 4/4 reproductions so far. Harness log signature:

\`\`\`
[copilot-harness] inference routing: mode=cli configuredModel="gpt-5.6-sol" endpoint=managed-by-copilot-cli
400 Bad Request
[copilot-harness] attempt 1 failed: exitCode=1 failureClass=http_400_response_error isCAPIError400=false isHTTP400ResponseError=true tokenCount=0 attemptDurationMs=1938 retriesRemaining=3
[copilot-harness] attempt 1: HTTP 400 response error — not retrying (persistent request validation/state failure)
\`\`\`

Key indicators:
- `tokenCount=0` — request appears rejected before any generation.
- `attemptDurationMs` under 2s — consistent with an immediate rejection, not a mid-stream failure.
- The harness classifies this as `http_400_response_error` (per #60647, "Detect standalone Copilot CLI HTTP 400 failures") and correctly does not retry it as a persistent validation/state failure — but that also means there's no automatic recovery path.

## A/B isolation

Rolling one of the two affected workflows back to gh-aw v0.88.7 / Copilot CLI 1.0.80 — same model, same repo, same time window, only the gh-aw/Copilot-CLI version differing — runs successfully with no other changes. This rules out general backend/model-availability flakiness and points at something in the 1.0.80→1.0.83 Copilot CLI range (or gh-aw's request construction in that version span).

## Possibly related

This may be the same underlying issue as #60785 (open) and #60651 (closed as `NOT_PLANNED`), both showing an identical `400 Bad Request` / `Duration 0s` / `Changes +0 -0` signature, but on a different model (`copilot/gpt-5.4`). If so this isn't model-specific but a broader Copilot CLI/backend regression that happens to reproduce reliably on the `gpt-5.6-*` family here.

## Impact

Both affected models are the *default* model for two separate production-critical review workflows in our setup, so this blocks adopting v0.89.x entirely until resolved or worked around.

## Ask

- What changed in Copilot CLI 1.0.80 → 1.0.83 (or gh-aw's request path in that version range) that could produce an immediate, zero-token 400 for these specific models?
- Is this the same root cause as #60785/#60651, or a distinct issue?

Start by reproducing the two affected workflows with gh-aw v0.89.13/Copilot CLI 1.0.83, then compare their harness logs and request path with v0.88.7/CLI 1.0.80. Investigate the standalone HTTP 400 classification and the model-specific request behavior, including related issues #60785 and #60651. Done means identifying the regression or confirming the shared root cause and documenting a validated resolution or workaround.

Written by the indexing model from the issue text.