feat: make MCP-driven TSL playground sessions work end-to-end

[devallibus]

Summary

Make a TSL playground session work end-to-end when driven through MCP in a browser that already supports WebGPU.

This issue is not about broad TSL architecture validation. It is about making the existing MCP ? web app ? SSE ? browser preview loop behave correctly for TSL sessions in the same way GLSL sessions already aim to.

Problem

The codebase already has TSL-shaped support across the stack:

• MCP accepts language: "tsl" and tslSource
• the playground session model persists shader_language and tsl_source
• the playground layout switches to a single-source editor for TSL
• PlaygroundCanvas delegates to TslPreviewCanvas

What is still missing is a proven and reliable roundtrip for agent-driven TSL sessions.

Today we do not have evidence that all of the following work together in one flow:

1. MCP create_playground creates a TSL session with initial source
2. Opening the returned session URL renders that TSL source in the playground
3. MCP update_shader with tslSource pushes changes through SSE and updates the live preview
4. The browser posts either a fresh screenshot or structured TSL errors back to the server
5. MCP receives the resulting screenshot or errors in the update_shader response

Scope

In scope:

• TSL session creation through create_playground
• TSL source updates through update_shader
• Browser-side live preview updates in TslPreviewCanvas
• Screenshot capture for successful TSL renders
• Structured error propagation for failed TSL updates
• Automated coverage for the TSL roundtrip at the server and browser boundary where practical

Out of scope:

• Non-WebGPU browser support beyond a clear existing fallback message
• Playground landing/onboarding UX
• General editor polish such as better TypeScript syntax highlighting
• Larger TSL runtime architecture changes unless required to make this path work

Acceptance Criteria

• create_playground accepts { language: "tsl", tslSource } and returns a usable session URL
• Opening /playground?session=<id> for that session shows the persisted TSL source in the editor
• A valid update_shader call with tslSource updates the browser preview for that session
• A successful TSL update causes the browser to post a screenshot and update_shader returns it when a preview client is connected
• An invalid TSL update causes the browser to post structured errors and update_shader / get_errors return them
• The supported-browser path is documented and manually verified in one real WebGPU-capable browser

Suggested Implementation Notes

• Treat this as a roundtrip reliability issue, not a schema issue. Most of the type plumbing already exists.
• Reuse the same response contract as GLSL where possible: success returns screenshot, failure returns errors.
• If TSL error kinds need refinement, keep them within the existing structured error model rather than inventing a parallel reporting path.
• Add at least one integration-style test or harness that prevents this flow from regressing again.

Follow-up Work

If needed, split separate follow-ups for:

• TSL editor syntax highlighting improvements
• richer no-WebGPU fallback UX
• broader browser compatibility support
• deeper TSL sandbox/runtime redesign