fix(systems): resolve templates in the deploy dry run (#1841)

[dolho]

What

The deploy dry run now resolves each local: template, so a manifest that cannot deploy stops reporting valid.

Related to #1841

Before / after, same manifest

name: sysprobe
agents:
  good: {template: local:dd-intake}
  bad:  {template: local:this-template-does-not-exist}

Before — status: "valid", warnings: [], failed: []. After, on a live instance:

{
  "status": "invalid",
  "failed": [{
    "name": "sysprobe2-bad",
    "short_name": "bad",
    "template": "local:this-template-does-not-exist",
    "reason": "Local template 'this-template-does-not-exist' was not found. Check the id against GET /api/templates — ...",
    "status_code": 404
  }],
  "agents_to_create": ["sysprobe2-good", "sysprobe2-bad"]
}

Why this and not a doc note

Recovery from a partial deploy is manual. The deploy path's own warning spells it out — re-running the manifest creates suffixed duplicates of the agents that already succeeded — so the fix is per-agent by hand. The preview is the control that avoids paying that, and the failure it was blind to (typo'd or renamed template id) is the cheapest mistake available. #1793/#1759 had just made an unresolvable local: template a hard 404 at create time; validation-time resolution is the matching half of that change.

Approach

The preflight calls the create path's own _resolve_local_template on a throwaway AgentConfig, instead of re-deriving "does this template exist". Two consequences worth reviewing:

• The preview cannot drift from the deploy. The reason string and status code an operator sees in a dry run are produced by the same code that will produce them for real — test_preflight_reason_matches_what_the_real_deploy_reports asserts that equality directly rather than hard-coding an expected message.
• The throwaway config matters: that resolver mutates the object it is handed (type/resources/tools/runtime from template.yaml), so the manifest's own config is never passed to it.

The import is lazy, matching the existing _default_create_agent_fn seam — a module-level import would close a cycle.

github: is deliberately not probed. Validating it means a network call to GitHub with the platform PAT on a preview endpoint: slow, rate-limited, and a new outbound call on a path that had none. So a dry run still cannot promise a github-template manifest deploys, and a test pins that the local resolver is never reached for one. Worth a second opinion during review — the alternative is an opt-in ?probe_remote=true.

status gains invalid for a preview with blockers, matching the deploy path's own partial / failed vocabulary rather than claiming success beside a populated failed[]. agents_to_create still lists the full plan, so the preview shows what was asked for and what blocks it. The response-model comment and the MCP deploy_system tool description are updated (Invariant #13).

Verification

pytest tests/unit/test_ent125_resilient_system_deploy.py
19 passed

4 new cases; reverted the preflight with the tests in place → 2 failed (the flagged-failure case and the preview/deploy equality case).

One fixture change to flag: the ent125 env fixture now stubs the resolver seam. The preflight reads the real catalog root (/agent-configs/templates), which does not exist under pytest, so without the stub every pre-existing dry-run test would have started failing — the same "new contract, old test" trap that blocked #1822.

Full unit suite posted below.

🤖 Generated with Claude Code

Fixes #1841

[dolho]

Full unit suite on this branch:

5042 passed, 16 skipped, 4 failed  (27:26)

FAILED tests/unit/test_1472_schedule_validation.py::test_accepts_valid[0 4 * * *-Europe/Kiev]
FAILED tests/unit/test_admin_email_login.py::test_admin_logs_in_with_username
FAILED tests/unit/test_admin_email_login.py::test_admin_logs_in_with_registered_email
FAILED tests/unit/test_admin_email_login.py::test_email_identifier_is_normalized

Same 4 environmental failures this repo shows on an untouched checkout: the first is a missing tzdata module, the other three trace to a bcrypt has no attribute '__about__' version mismatch that also appears in the backend boot log. Neither is touched by this PR — identical set on #1843 and #1847.

[vybe]

Validated via /validate-pr: diff reviewed, security greps clean, touched unit tests pass locally on a combined worktree with all four post-release fix PRs (167 passed). Merging.