fix: apply reasoning effort to launch-time model overrides

[mrubens]

Follow-up to #433: the reasoning-config gap this fixes is also what made #433 invisible in ad-hoc testing.

Problem

A launch-time model override (the model picker in the task launcher, or harnessModelOverrides from the API) only received a reasoning effort when it happened to equal the deployment's configured coding model or code-review model. Any other pick ran with no reasoning configured at all — quietly different behavior from the same model configured as a role default, and the reason the #433 bug never surfaced when spot-checking models from the launcher.

Separately, the task payload's reasoningEffort field — documented as "per-task override for the model reasoning effort used at runtime" and accepted by the public launch API — was never consumed by workers.

Fix

Control plane (resolveEffectiveHarnessModelState): when a launch selects an opencode-server model override and no explicit per-task effort is set, stamp payload.reasoningEffort — inheriting the deployment's coding-role level (env or persisted), falling back to the coding default (medium), and skipping models whose catalog metadata reports supportsReasoning: false (unknown support keeps the default, matching the runtime-env resolution). Deployment-default launches are not stamped, so their behavior is unchanged. Explicit per-task efforts (public API) always win.

Worker: plumb payload.reasoningEffort through the harness (create-harness → startOpenCodeServerHarness → generateOpenCodeConfig) and apply it to the effective coding model with precedence over the role-configured levels.

Side benefits: the public API's reasoningEffort field now actually works, and the task info panel (which already renders payload.reasoningEffort) now shows the effort for override launches.

Validation

• New unit tests: stamping for overrides (default + inherited level), explicit-effort precedence, supportsReasoning: false skip, no stamp on deployment-default launches, snapshot-resume reuse, worker plumbing end to end (generateOpenCodeConfig emits reasoning options for the override model), and the create-harness passthrough.
• Full @roomote/cloud-agents (482) and worker (1374) suites pass; pnpm lint + pnpm check-types clean.

[mrubens]

Addressed the P2: resolveEvalHarnessSelection no longer rejects reasoningEffort — the hard 400 predated the worker plumbing and blocked both the public launch API and Slack !eval --reasoning (all callers share this validator, so the one change unblocks every surface). Added API tests asserting the effort reaches the enqueued task payload, with and without a model override.