fix(trainer): don't resolve Hub envs when parsing orchestrator configs

[eexwhyzee]

Problem

discover_runs() builds OrchestratorConfig to read training-relevant fields (model, lora, seq_len, buffers, env names), but constructing a v1 env config eagerly resolves (imports/installs) its taskset/harness plugins from the Environments Hub. On the trainer that 404s for private hub envs (taskset.id = owner/name@version) — the trainer has no Hub credentials — so get_orchestrator_config() returns None and the run is silently skipped.

Fix

Parse under verifiers' skip_plugin_install contextvar so the trainer never touches the Hub while reading the config. The env server still installs the plugin at runtime.

Dependency / sequencing

1. Merge the verifiers PR: fix(v1): don't install envs from the Hub during config parse verifiers#2084
2. Bump deps/verifiers to a commit that includes skip_plugin_install (separate PR)
3. Mark this ready for review

🤖 Generated with Claude Code

---

Note

Low Risk
Narrow change to config-load path only; does not alter training or env execution, but adds a hard dependency on the new verifiers API until the submodule is bumped.

Overview
Fixes runs with private v1 Environments Hub tasksets being silently dropped during trainer run discovery.

get_orchestrator_config() now parses OrchestratorConfig under verifiers’ skip_plugin_install context so construction does not resolve or install taskset/harness plugins from the Hub. The trainer only needs training fields from the TOML and never executes the env; without this, private hub refs (taskset.id = owner/name@version) 404 when the trainer has no Hub credentials and discover_runs() skips the run. Hub plugin install still happens on the env server at runtime.

Note: Depends on a verifiers release that exports skip_plugin_install (separate submodule bump).

^{Reviewed by Cursor Bugbot for commit 8c29313. Bugbot is set up for automated code reviews on this repo. Configure here.}