feat(testmanagement): create test cases with a custom template (template_id) + listTestCaseTemplates

[gaurav-singh-9227]

What & why

Follow-up to #319 (which added a template param that only selects system templates). This adds the ability to create a test case with a custom template, plus a way to discover template ids. Both verified end-to-end against prod.

The key finding

A custom template can only be selected by numeric template_id — the template slug only ever picks a system template (step_type is constrained to test_case_steps/test_case_bdd and isn't unique).

The catch: the public v2 create endpoint silently strips template_id (proven — a project-linked custom template id still applied the default). But the v1 create endpoint honours it. So:

• When template_id is set, createTestCase routes to POST /api/v1/projects/{numericId}/test-cases (API-TOKEN auth, folder in the body) instead of v2.
• v1 keys custom_fields by id with option ids, whereas v2 keys by name with values — so on the v1 path we translate the by-name shape → v1's by-id shape via the project's form fields, keeping multi-select custom fields working alongside a template.
• With no template_id, the proven v2 path is unchanged — zero regression for the common case.

Changes

• list-templates.ts — listTestCaseTemplates tool → GET /api/v1/admin-v2/settings/templates?entity_type=TestCase (API-TOKEN), client-side name filter.
• create-testcase.ts — template_id param; v1 routing when set; toV1CustomFields translation; post-create read-back that warns if the applied template differs.

Testing

npm run build green — lint, format, tsc, and 198 tests pass.

Existing tests (sanity)

The pre-existing testmanagement suite is unchanged and still green — notably the v2 default create path, priority normalization, the template system-slug pass-through + silent-fallback warning, and the multi-select custom_fields-by-name behaviour from #319 all continue to pass (this PR leaves the no-template_id path entirely on v2).

New tests (9)

createTestCase — template_id routing & verification (6)

1. passes template_id through to the request body and does not warn when applied — template_id reaches body.test_case.template_id; no mismatch warning when the applied template equals the requested one.
2. warns when the API applies a different template_id than requested — if the created case comes back with a different template_id, the tool surfaces a clear mismatch warning instead of reporting plain success.
3. does not emit the slug warning when template_id is supplied (id takes precedence) — the template system-slug fallback warning is suppressed when template_id is present, so the two paths don't double-warn.
4. reads the case back and warns when template_id is omitted from the create response but not applied — the real create response has no template_id, so the tool re-reads the case via the v1 search endpoint and warns when the applied template differs (covers the silent-miss failure mode).
5. routes to the v1 create endpoint with API-TOKEN auth when template_id is set — asserts the request targets /api/v1/projects/{id}/test-cases with the API-TOKEN header (not v2 + Basic), the folder is carried in the body (folder_id top-level and test_case.test_case_folder_id), and MCP-only params (project_identifier, folder_id) do not leak into the test_case payload.
6. translates custom_fields name→id and option value→id on the v1 path — with form fields mocked, { aaas: ["m40","m48"] } (v2/by-name shape) is rewritten to { 194184: [111, 222] } (v1/by-id shape) in the request body.

listTestCaseTemplates (3)

7. queries the admin-v2 templates endpoint with API-TOKEN auth and surfaces ids — hits GET /api/v1/admin-v2/settings/templates?entity_type=TestCase with the API-TOKEN header and returns each template's numeric id and name.
8. filters by name client-side — a name argument narrows the returned list (matching template kept, non-matching default dropped) and the count reflects the filtered set.
9. reports when no templates match the name filter — returns a clear No templates matching "…" message rather than an empty/confusing result.

End-to-end verification (prod, throwaway folder, deleted after)

Path	Result
listTestCaseTemplates via compiled tool	returned real templates with ids ✅
createTestCase with a custom template_id	applied that template (not the default) ✅
createTestCase with template_id + multi-select custom_fields + priority + tags + steps	applied the requested template and both custom-field values, plus priority/tags/steps — isError:false ✅
createTestCase with an invalid template_id	rejected with a clear error, nothing created (no silent fallback) ✅
createTestCase with no template_id (v2 path)	unchanged ✅

Server boots clean and registers all tools.

Notes / limitations

• BDD custom templates would also need feature/scenario fields on the schema (today's schema is steps-oriented) — out of scope.
• The v1 create path uses API-TOKEN auth + numeric project id, consistent with the existing form-fields / project-lookup calls.