feat(dq): add DQ rule lifecycle + job observability MCP tools

[regmimridul]

🎯 What does this PR do?

Adds MCP tools to author, manage and observe data-quality rules and job runs on an existing DQ job (DEV-198734). Together they cover a rule's full lifecycle: preview/validate → create → read → edit → delete, plus run the job and observe the outcome.

Rule authoring & lifecycle (CRUD)

• create_dq_rule — create a rule (monitor) on a job via the DQ monitoring API (POST /rest/dq/internal/v1/monitoring/monitor). monitorType is FREEFORM_SQL (full SQL) or SIMPLE_SQL (single-column check); supports filterQuery, columnName, dimensions, tolerance, and template linkage. Defaults to active and not suppressed.
• get_dq_rule — read a single rule's definition (GET /rest/dq/internal/v1/jobs/{jobName}/monitors/rules/{monitorName}).
• edit_dq_rule — update an existing rule; full-replace, with newMonitorName to rename (PUT /rest/dq/internal/v1/monitors/rules).
• delete_dq_rule — delete a rule from a job (DELETE /rest/dq/internal/v1/jobs/{jobName}/monitors/rules/{monitorName}). Marked destructive.

Pre-flight & results

• validate_dq_rule — validate a rule's SQL/definition before saving or running, so a malformed rule is caught up front (POST /rest/dq/internal/v1/rules/validate).

• preview_dq_rule_sql — run the rule's SQL and return sample columns + rows (POST /rest/dq/internal/v1/rules/previewRule).

• get_dq_rule_results — per-run results after a job run: score, breaking/passing counts, pass/fail, exceptions; paginated (GET /rest/dq/internal/v1/monitoring/rules/{jobName}/{ruleName}).

  (validate_dq_rule / preview_dq_rule_sql take edgeSiteId/connectionId/schemaName — the discovery output from prepare_create_dq_job.)

Job run & observability

• run_dq_job — trigger a run of an existing job, executing its rules (POST /rest/dq/1.0/jobs/{jobName}/run). Optional runDate/runDateEnd (dateKind DATE/TIMESTAMP) and backrun backfill; defaults to current date/time. Returns the jobRunId.
• get_dq_job_status — status of a run by jobRunId via the public API (GET /rest/dq/1.0/jobRuns/{jobRunId}): run status (RUNNING/FINISHED/FAILED…), activity, score, breaking-monitor count, failure exception.
• get_dq_job_log — execution log for a run (stages, timings, exceptions). Uses the internal DQ UI surface (GET /rest/dq/internal/v1/job/logs?jobUUID={jobRunId}) — the public DQ API has no log endpoint.

All tools validate inputs before any call, surface downstream DQ errors (400/403/404/422) as structured results, and are covered by unit tests. API contracts were taken from the dq (udq-app) controllers/OAS, not guessed. README updated with all entries.

Refs: DEV-198734

✅ 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

[svc-snyk-github-jira]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[aberkowCollibra]

@regmimridul do we have tests on the DQ side to ensure these API contracts will not change and will fail if someone modifies?

[EricWarnerCollibra]

@regmimridul I would have the same comment as here -> #88 (comment)

[aberkowCollibra]

I recommend not including this endpoint since it returns live client data. I'm not sure if the results get passed into the LLM and we'd need to verify before we can go down this path.

[regmimridul]

@aberkowCollibra @EricWarnerCollibra removed the preview_dq_rule_sql endpoint and updated the PR to use less of Collibra jargon. Will be adding tests to ensure that the API contracts do not change shortly.