fix(headless): route DeepSeek OpenCode through host proxy

[Astro-Han]

Summary

Our own canary smoke run (deep-swe-1.1-full | deepseek-v4-flash-max | opencode, LIMIT=5) caught what two review rounds missed: every OpenCode competitor cell fails infra_failed / auth — the CLI dials https://api.deepseek.com directly and Pier's Squid egress proxy denies it (x-squid-error: ERR_ACCESS_DENIED), because opencode-benchmark.json has no deepseek provider section routing it through the host credential proxy. The published TB2.1 DeepSeek report ran from the branch that carried this fix; when #1730 cherry-picked only the runtime profile, the config section stayed behind — so both DeepSeek×OpenCode compositions on main (terminal-bench-2.1 and deep-swe-1.1-full) are affected.

Cherry-picks 23b6bef7c unchanged: adds the deepseek provider section ({env:DEEPSEEK_API_KEY} / {env:DEEPSEEK_BASE_URL} placeholders, which the adapter's _runtime_env already populates from the per-attempt proxy lease) plus the contract assertion.

Verification

• Canary evidence: opencode.txt error event shows Squid 403 for https://api.deepseek.com/*; the maka cell of the same pair completed, isolating the failure to the OpenCode provider routing
• Targeted adapter contract test (config section + ephemeral-token env mapping): pass
• packages/headless suite: 1448 pass / 0 fail; format/lint clean
• End-to-end re-verification (resumed canary opencode cells) follows merge

Review focus

The failure mode proves why runtime profiles and provider routing must land together; nothing else in the run path changed.