feat: add assessment tools (get, create, edit)

[bobby-smedley]

🎯 What does this PR do?

Adds three MCP tools for Assessments — the questionnaires you conduct in the Assessments application (DPIA, PIA, EU AI Act, …).

Why new tools instead of extending edit_asset: assessments aren't catalog assets. They're not addressable by a catalog UUID, they live behind a different API (assessments.public.v2), and their shape (questions/answers/status) has nothing to do with attributes/relations. So they get their own tools — the same way lineage, classification, and data contracts do. edit_asset is untouched.

The tools (each takes a name or UUID):

• get_assessment — read one, or filter by name/status/template/asset/date range (paginated).
• create_assessment — conduct a new one from a template (template given by name or UUID). No prepare step: the create response returns the questions to fill in.
• edit_assessment — set answers + status/name/owner/assignees/visibility, applied as one atomic PATCH (all-or-nothing). Supported answer types: TEXT, HTML, EXPRESSION, NUMBER, BOOLEAN, DATE, ITEMS. ASSETS/USERORGROUPS/ATTACHMENTS return a clear "not yet supported" error (follow-up).

All requests go through the existing shared client (relative paths, shared host + auth), so no new auth wiring.

Testing: verified live end-to-end against a dev instance — create, name lookup, filtered reads, and edits (scalar, ITEMS, and filling blank questions) all work. One known env issue, not from this code: moving an assessment to SUBMITTED returns a backend 500 on that instance, so that transition couldn't be exercised there. Unit tests cover the answer-type coercion and the output-schema shape.

✅ 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 (README + server instructions).
• My commit messages follow the Conventional Commits standard.