feat(orchestrator): expose target_lag config

[Abhishek21g]

Summary

TARGET_LAG was a hardcoded module constant gating how many batches the orchestrator may ship ahead of policy.version. Operators confused it with max_off_policy_steps (#2812).

• Add orchestrator.target_lag (Field(1, ge=1)) with docs distinguishing the two knobs
• Update docs/training.md useful-knobs table
• Config validation tests (default=1, reject 0)

Default 1 preserves current behavior exactly.

Related: #2812 (note PR #2845 also open — happy to consolidate)

Verify

uv run pytest tests/unit/orchestrator/test_off_policy_lag.py -k target_lag -v

---

Note

Low Risk
Behavior is unchanged at the default; the change is config wiring and documentation with minimal orchestrator logic touched.

Overview
Replaces the hardcoded dispatch-gate constant with orchestrator.target_lag (default 1), so operators can tune how many batches the orchestrator may ship ahead of policy.version without changing code. update_dispatch_gate now compares lead against self.config.target_lag instead of a module-level TARGET_LAG.

Docs clarify that target_lag (dispatch pause / watch time/wait_for_policy) is separate from max_off_policy_steps (per-rollout staleness discard). Config field docstrings mirror that split. Unit tests cover default 1 and rejection of 0.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit e482ab3. Configure here.}