Expose values-schema validation via REST API + schema-driven values UI editor

[alexmond]

Follow-up to #816 (full JSON Schema validation via NetworkNT). Once the core validator is spec-complete, expose it and build on it.

Part A — REST API for schema + values validation (jhelm-rest)

The engine already loads a chart's values.schema.json into Chart.valuesSchema and validates on render/lint. Surface that directly so a client (or the UI in Part B) can fetch the schema and validate arbitrary values without a full template render.

Proposed endpoints on ChartController (repo chart ref + uploaded .tgz variants, mirroring the existing /template + /template/upload pairing):

• GET/POST /api/charts/schema — return the chart's values.schema.json (raw JSON), plus its default values.yaml. 404/empty when the chart declares no schema.
• POST /api/charts/validate — body: chart ref + candidate values; returns a structured result: valid: bool + a list of { pointer, keyword, message, schemaLocation } (the NetworkNT OutputUnit detail shape from Full JSON Schema validation for values.schema.json (replace hand-rolled validator with NetworkNT) #816, mapped to a DTO — do NOT leak the library type).

Notes:

• Reuse the Full JSON Schema validation for values.schema.json (replace hand-rolled validator with NetworkNT) #816 SchemaValidator; add a variant that returns the structured error list instead of throwing, so the controller can return 200 with valid:false rather than an exception. Keep the throwing validate(...) for Engine/lint.
• Swagger/OpenAPI annotations, proper status codes (security.adoc posture: READ_ONLY + api-key by default for REST).
• New DTOs under jhelm-rest/.../dto (ValuesValidationRequest, ValuesValidationResult, SchemaValidationError).

Part B — Values UI editor (schema-driven)

A browser editor that renders a form from the chart's values.schema.json, edits values live, and validates against Part A.

• Schema-driven form generation (types, enums→dropdowns, required, min/max, descriptions as help text, defaults as prefills).
• Live validation via POST /api/charts/validate; inline error markers keyed by JSON pointer.
• Raw-YAML toggle alongside the form (two-way).
• Optional: "diff vs chart defaults" and a "render template with these values" action (reuses /template).

Open design questions (decide before building B):

• Where does the UI live? A new module (e.g. jhelm-ui static SPA served by jhelm-rest) vs a separate repo. Lean: static assets served by jhelm-rest so it ships with the API, no extra deploy.
• Framework. Plain + a JSON-Schema form lib (e.g. JSON Forms / react-jsonschema-form) vs hand-rolled. A schema-form lib gets 80% for free and tracks the same drafts as Full JSON Schema validation for values.schema.json (replace hand-rolled validator with NetworkNT) #816.
• Draft coverage. The form lib must handle whatever Full JSON Schema validation for values.schema.json (replace hand-rolled validator with NetworkNT) #816 supports (2020-12 default, Draft-07 via $schema).

Slices

1. (A) SchemaValidator non-throwing structured-result variant + DTOs.
2. (A) ChartController schema + validate endpoints (repo ref + upload), Swagger, tests.
3. (B) UI module scaffold + schema-driven form + raw-YAML toggle.
4. (B) Live validation wiring + render action.

Depends on #816.