DEV-205663: Add rule template create, update and delete tools

[regmimridul]

🎯 What does this PR do?

DEV-205663. Adds three write tools over the public DQ rule template API, so the template library can be managed programmatically instead of through the UI.

• create_data_quality_rule_template — POST /rest/dq/1.0/ruleTemplates. Returns the created template with its assigned id; a duplicate name (409) is reported as such rather than overwriting.
• update_data_quality_rule_template — PUT /rest/dq/1.0/ruleTemplates/{name}. Partial update by name; returns the per-deployment cascade outcomes and reports partial when some deployed rules were skipped.
• delete_data_quality_rule_template — DELETE /rest/dq/1.0/ruleTemplates/{name}?deleteDeployments=. cascade=false (default) refuses while deployments are live and reports the count.

New client code in pkg/clients/dq_template_write_client.go (create/update/delete, reusing the existing dqDo helper) and pkg/clients/business_rule_assets_client.go (Business Rule asset name → UUID resolution). Two small additions to dq_templates_client.go: a businessRuleAssetIds field on DQRuleTemplate, and a ErrDQRuleTemplateNotFound sentinel wrapped around the existing 404 so the write tools can distinguish "no such template" without matching on message text.

All three carry the confirm checkpoint from docs/TOOL_CONTRIBUTION_STANDARDS.md §5 — confirm=false (default) previews and writes nothing, confirm=true performs the write — and the preview echoes every field that will be sent (§5.2).

Where the API does not do what the ticket assumed

Three acceptance criteria describe behaviour the public API does not provide. Each is implemented in the tool instead; flagging so the ticket can be corrected.

Ticket AC	API reality	What this PR does
Update is PATCH, partial	It is a PUT and the payload requires ruleTemplateName, sql, dialect, description, dimensions	Reads the template and merges, so omitted fields keep their stored values. tolerance is carried through even though the tool cannot set it — otherwise a PUT would silently wipe it
Update takes cascade (default false); false leaves deployments untouched	No such flag. The update and its cascade are one transaction	No cascade switch is exposed. The preview reports how many deployed rules will be affected, and the result reports per-rule DEPLOYED/SKIPPED/FAILED
Delete errors if the template is missing	Delete is idempotent — 204 even when nothing matched	Existence is checked with a GET first
Delete errors if deployments exist and cascade=false	No such API error	deployedRuleCount is checked first and the delete is refused client-side, with the count in the message

Two smaller mismatches:

• description and dimensions are required, not optional. The API's write payload requires both (dimensions with minItems: 1). Per §6.1 the tools reject a missing one up front with a self-correcting message rather than letting it surface as a raw 400.
• dialect is not an enum. The ticket describes it as one; the spec has a free-form string (1–255 chars) validated server-side. Documented that way, and the service's rejection is surfaced with context.

Decisions taken against the ticket

• Tool names spell out the domain — create_data_quality_rule_template, not dq_create_rule_template — per §4.1, and matching the three sibling template tools already on main (list_/get_/deploy_data_quality_rule_template, §6.5). Worth noting the newer job tools (dq_get_job, dq_get_job_run) use the short form, so the repo currently has both conventions live; that is a wider cleanup, not one for this PR.
• Delete has a confirm checkpoint, although the ticket says confirmation is the caller's responsibility. §5.1 is explicit that a checkpoint the model can skip is not a checkpoint, and this is the only destructive tool in the set. Happy to drop it if the team disagrees.
• Registered ungated, matching the other DQ tools on main today. §3.1 says write tools should sit behind an experimental flag, but the data-quality flag was removed in feat(dq): remove data-quality experimental flag DEV-215225 #126 and Revert #126: restore the data-quality experimental flag #129 proposes restoring it — if Revert #126: restore the data-quality experimental flag #129 lands, these should join that block.
• tolerance is not exposed as an input, since the ticket's field list omits it (§1.2, narrowest surface). It is preserved through updates rather than being settable.
• No rename. The API supports renaming via the update payload, but it changes the template's URL and leaves no alias, and the ticket does not ask for it.

Impact Analysis

Medium — these are the first tools that mutate the rule template library, and delete with cascade=true removes rules from live jobs, which stops those checks running on future job runs. That path is guarded three ways: the delete is refused outright unless cascade=true is passed explicitly, the confirm checkpoint means the first call always previews and writes nothing, and the preview states the exact number of deployed rules that would go. delete is the only tool marked DestructiveHint: true.

Otherwise additive: three new tool packages, two new client files, three lines in RegisterAll. The only changes to existing code are the two small additions to dq_templates_client.go described above; the 404 sentinel keeps the same error text ordering and get_data_quality_rule_template's tests are unaffected.

Out-of-the-box (system) templates are rejected before any write in both update and delete, matching the ticket's "read/apply only" scope.

Per §8.2 the client was written against udq-app-client/oas/dq-v1-public-oas-spec.yaml in the dq repo, not from guesswork. §8.3 contract tests on the DQ side are not part of this PR.

Verified with gofmt -l, go build ./..., go vet ./... and go test — new package suites plus pkg/tools and pkg/clients, all passing. Tests cover the confirm checkpoint writing nothing, the merge preserving untouched fields, cascade refusal with a live deployment count, name-vs-UUID business rule resolution including the ambiguous case, and 409/400 surfacing.

✅ Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation (if needed).
• My commit messages follow the Conventional Commits standard.

🤖 Generated with Claude Code