Fix template updates to require explicit version labels

[cursor]

Description

Fixes a high-impact template update bug where harness_update(resource_type="template") silently defaulted missing version_label to v1. That could mutate the wrong template version when callers intended to update another version such as stable.

The handler now resolves the target version only from explicit inputs: params.version_label, body.version_label, body.versionLabel, or body.label. If no version is provided, it returns a user-fixable error before dispatching any Harness API request.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other

Checklist

• Tests pass
• Typecheck passes

Verification:

• pnpm test tests/tools/tool-handlers.test.ts
• pnpm typecheck
• pnpm build
• pnpm test

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cursor]

Found 1 architecture-level issue to address before merge.

I verified the branch on a clean PR snapshot with pnpm test tests/tools/tool-handlers.test.ts, pnpm typecheck, pnpm build, and full pnpm test (53 files / 1308 tests passing). CI is also green. The remaining problem is a shared-tool contract gap in harness_update for template updates.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

harness_update() already coerces JSON-string bodies into objects via coerceRecord(body), but this template-specific version extraction reads args.body instead of the coerced form. That leaves a supported shared-tool input path broken: body: JSON.stringify({ label: "stable", template_yaml: "..." }) still returns version_label is required... instead of targeting /versions/stable.

I reproduced this on the PR head with a focused Vitest case against the registered tool handler. Please read the version aliases from coercedBody (or input.body) here and add a tool-level regression test for the JSON-string body path so the generic update contract stays consistent.