fix(assets): update aigateway to 0.6.0

[lucas77778]

Summary

• update the managed aigateway sidecar from v0.5.0-rc2 to v0.6.0
• pin the exact compressed sizes and SHA-256 SRI values for all five supported release artifacts

Why

v0.6.0 accepts inline Anthropic system messages, fixing local requests that failed with HTTP 400 unknown variant system.

Checks

• pnpm check:ci
• pnpm test
• downloaded all five release artifacts and verified them against the published SHA256SUMS
• ran the Linux x64 binary and observed aigateway 0.6.0

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[pullfrog]

✅ No new issues found.

Reviewed changes — the single-commit bump of the managed aigateway sidecar pin, verified against the published upstream release and the v0.5.0-rc2↔v0.6.0 source diff.

• Version pin 0.5.0-rc2 → 0.6.0 — one constant at catalog.ts:123 that simultaneously moves the download URL, the store path (<root>/tool/aigateway/<version>/aigateway), and the GC's notion of the wanted version.
• Five re-pinned artifacts — new SRI digest and byte size for each supported platform; no platform added or removed, win32-arm64 still correctly absent.

What I verified independently rather than taking on trust:

• Every digest and size matches the release exactly, cross-checked two ways: the Release API's assets[].digest (sha256:<hex> re-encoded to base64) and the SRI column in the v0.6.0 release notes. The release is neither a draft nor a prerelease.
• The URL template still resolves. The release publishes aigateway-0.6.0-<triple>.tar.gz / .zip, which is exactly what aigatewayArtifact() builds at catalog.ts:135.
• The spawn contract is intact. Upstream src/ and providers/aigw-openai-compat/ are byte-identical between the two tags, so serve --host --port --config, the single stdout line that LISTENING_RE parses, stderr-only tracing, and the [upstream] TOML keys upstreamToToml writes all still hold.
• The stated fix is real and reaches our path. The only upstream code that moved is providers/aigw-anthropic/: Role::System is now accepted on deserialize and AnthropicRole::System maps into the inbound native bridge, so an inline system message no longer 400s with unknown variant system.
• Nothing else in the repo pins the old version, and no test asserts an aigateway version or digest.

ℹ️ Two pre-existing gaps in the sidecar config, surfaced by re-reading the 0.6.0 contract

Neither is introduced or amplified by this PR — both behave identically under the currently pinned 0.5.0-rc2 — so nothing here blocks the merge. Flagging them because this bump is the natural moment to decide whether they are worth tracking.

Technical details

# Sidecar config surfaces the daemon never writes

## Affected sites
- `apps/daemon/src/ai-gateway.ts:48` (`upstreamToToml`) — writes only `base_url`, `api_key`,
  `wire`, and an optional `default_model`. It never writes `[upstream.models]`, so
  `GET /v1/models` answers `{"data": [], "has_more": false, …}`: upstream
  `advertised_models()` is literally `config.models.keys()` (`src/bridge.rs:143`). The upstream
  `docs/gateway-sidecar.md` states Claude Code probes that route at startup and advises keeping
  the map populated. The `/v1/messages` path itself is unaffected — with no map, `resolve_model`
  falls back to `default_model`, or forwards the inbound Anthropic model name unchanged.
- `packages/host/engine/src/agent/translator.ts:15` and
  `packages/foundation/providers/src/resolve.ts:141` — both comments say the sidecar implements
  only `openai-chat`. The sidecar's `Wire` enum has carried `openai-responses` since at least
  0.5.0-rc2 (it lives in the byte-identical `src/config.rs`), and `resolve.ts` consequently
  marks an `openai-responses` account `unavailable` for claude-code even though the sidecar
  could serve it.

## Open questions for the human
- Is an empty `/v1/models` response benign for the claude-code startup probe, or should
  `upstreamToToml` emit an `[upstream.models]` entry for the account's model? I could not settle
  this without driving a real claude-code session against the sidecar.
- Is leaving `openai-responses` unreachable for claude-code a deliberate scope decision, or
  just a stale comment nobody revisited? If deliberate, the two comments are the thing to fix;
  if not, that is its own issue rather than part of a version bump.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[linear-code]

PLAT-236