feat(extensions): add local text-to-diagram rendering API

[tang-vu]

Why this matters

Documents, scripts and local agents can render text diagrams without sending their source to a public rendering endpoint. Add an optional Kroki service through the existing catalog/install lifecycle, with concrete local API examples and an API-service dashboard label.

Contract

• Pin upstream yuzutech/kroki:0.32.1@sha256:6980bfb218b48b74ea14b888d9c7e8c032d1cb6325f3292277abdf62483abd9d, inspecting the exact Java server, PlantUML implementation and Dockerfile. Run UID/GID 1001, read-only root, no host data mounts, temporary scratch, dropped capabilities and loopback 7829 -> 8000.
• Explicit secure mode/PlantUML sandbox, 1 MiB main-server request limit (KROKI_BODY_LIMIT, not the companion-only similarly named setting), five-second native-command and twenty-second Java-conversion limits, 2 CPU/1.5 GB memory. Preserve image logging options by setting the heap through JAVA_TOOL_OPTIONS.
• Includes the main image's native renderers; optional Mermaid/BPMN/Excalidraw/diagrams.net companions are not started or advertised as working. No automatic remote fallback. Health performs a bounded GET, because this exact server registers GET /health and returns 404 to HEAD.
• Handoff: manifest/recipe -> catalog -> installed Compose -> HTTP health and explicitly configured client -> saved output. The service is stateless: keep diagram source/output externally, and roll back the image without a data migration.
• Full canonical catalog regeneration also restores the already tracked disabled pixel-inference metadata without activating it.

Overlap check

Searched open/closed PRs for Kroki, diagram rendering and the new production recipe paths; no Kroki PR exists. #4924 is an interactive draw.io editor, whereas this is a text-to-image API for automation. #1613 covers generic headless metadata; this recipe follows the current dashboard API-service mechanism. #5003 adds a different LanguageTool API ID to the same set, and combined integration must retain both. Shared catalog/README additions remain independently installable services.

Validation

• Exact-image Linux amd64: 2 passed (24-live-get-health, 217.01 seconds of pytest). Actual health/version, Graphviz SVG with Unicode, compressed-source GET, PNG signature/dimensions, PlantUML SVG, malformed input 400, oversized request 413, and repeated container recreation.
• A controlled HTTP source is first fetched successfully from inside the container. Rendering a PlantUML include then makes no request to that reachable source. Neither the remote canary nor a mounted local canary appears in the rendered SVG. This tests actual secure-mode behavior (includes are stripped), not an unreachable-server false positive. Fixtures are cleaned up.
• Initial live test caught HEAD /health returning 404; corrected the recipe to GET before publication. No success is claimed for that failed run.
• Dashboard full-page tests: 16 passed; lint 0 errors / 598 baseline warnings; production build passed. 36 manifests, scoped hooks and git diff --check passed.
• Full local make gate still reproduces the root/WSL no-sudo Docker baseline failure, covered by existing fix(installer): honor unavailable sudo in Docker fallback #3158. Added path-filtered CI runs the real render test; no full local gate pass is claimed.

Review and limits

Draft pending independent recipe review and CI. Image advertises amd64/arm64; live evidence covers only Linux amd64 under WSL. No native Windows/macOS/ARM, real editor integration, large/concurrent workload, optional companion or every bundled renderer was tested. These controls are not a general sandbox guarantee; upstream supplies no API authentication, so remote use needs an operator-managed protected path and trusted clients.