draft: Feat/visual api tester and templates

[royendo]

Adds a visual API tester and starter templates to the API workspace in Rill Developer.
Loom: https://www.loom.com/share/ace6427a03a04c10ad407994efc3049a

• API test panel: inline panel below the editor to execute GET requests against the current API endpoint, with a resizable response preview (table + JSON views) and dynamic query args
• Starter templates: dropdown in the workspace header with pre-built YAML templates (SQL, Metrics SQL, OpenAPI, Resource Status) that overwrite the editor content after confirmation
• APIWorkspace: new dedicated workspace component for .yaml API files, wiring up the editor, test panel, error mapping, rename, and template selection
• APIResponsePreview: renders API responses as a PreviewTable or formatted JSON, with type inference from sample rows
• APIEditor: wraps the existing YAML/SQL editor with the test panel and line-level error display

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

---

Developed in collaboration with Claude Code

[royendo]

UX/Product Review

Note: CI has a svelte-check error (error prop type mismatch on WorkspaceEditorContainer) and an unused import (mapParseErrorsToLines). e2e failures appear unrelated.

Must-fix

1. Switching API types destroys content without confirmation
Clicking a different type card (e.g., Metrics SQL → SQL) immediately calls handleTypeChange() which deletes all type-specific fields and replaces with defaults. A complex query is permanently gone. This is the most dangerous UX pattern in the PR. Add a confirmation dialog at minimum, or preserve previous content so users can switch back.

2. Args state is not shared between editor modes
The code editor and visual editor maintain separate args states. Test arguments entered in one mode are lost when switching to the other. Users expect to be editing a single artifact. Lift args into APIWorkspace and pass it down.

Should-fix

3. Textarea is a jarring downgrade from CodeMirror
Every other editor in Rill uses CodeMirror with syntax highlighting, line numbers, and bracket matching. The visual editor's SQL input is a plain <textarea> — no highlighting, no auto-complete, fixed 224px height. At minimum, auto-resize the height. Ideally, use a CodeMirror instance for SQL.

4. Template application is destructive and non-undoable
applyTemplate() silently replaces the query with no confirmation and no undo. The getBaseQuery() function uses naive string matching (indexOf(" where ")) that breaks on "where" in aliases or string literals. Consider a confirmation when content would substantially change.

5. No reconciliation awareness on "Test API" button
The button is disabled on errors but not during reconciliation. Clicking during a reconcile cycle hits a stale/errored endpoint. Disable during reconciliation with a spinner, matching ModelWorkspace pattern.

6. No copy-to-clipboard for the endpoint URL
URL displays in both editor modes truncate without a copy affordance. Since the primary use case is "build API, copy URL, paste into another system," this is a meaningful omission.

Moderate

7. Resource Status card is misleadingly presented as a peer of SQL types
The three API type cards (Metrics SQL, SQL, Resource Status) appear as equal peers, but Resource Status is fundamentally different — diagnostic, not data query. Consider visual differentiation or moving it to an "Advanced" section.

8. JSON response view lacks quality-of-life features
JSON.stringify in a <pre> tag — no syntax highlighting, no collapsible nodes, no search, no copy button, no row count. The table view via PreviewTable is much more functional.

9. Code editor Resizer has hardcoded max={500}
The visual editor's max is dynamic based on container height. The code editor's fixed max wastes space on large monitors. Use the dynamic approach in both.

Minor

10. API response empty state could be more actionable — contextual hints per API type would help.

11. Code editor's args dropdown is awkward for 3+ arguments — the visual editor's inline approach is superior. Consider a collapsible inline section for the code editor too.

12. No keyboard shortcut for "Test API" — Cmd+Enter would reduce friction for keyboard-driven workflows.

---

Developed in collaboration with Claude Code