bug: GLSL compilation errors not reported to server/MCP

[devallibus]

Summary

When an invalid GLSL shader is pushed to the playground (via API or MCP update_shader), the canvas goes black but no compilation errors are reported back to the server. The get_errors MCP tool always returns empty arrays, making it impossible for agents to know their shader failed.

Root Cause

In PlaygroundCanvas.tsx:194, error detection relies on gl.getParameter(gl.CURRENT_PROGRAM) returning a non-null program:

const glProgram = gl.getParameter(gl.CURRENT_PROGRAM)

if (glProgram) {
  // Check vertex shader errors...
  // Check link status...
}

When a shader fails to compile, Three.js does not set a current program — glProgram is null and the entire error-checking block is skipped. The ShaderMaterial constructor (line 168) doesn't throw on bad GLSL either; it just logs THREE.WebGLProgram: Shader Error to the console.

Reproduction

1. Start dev server (bun run dev:web)
2. Create a session: curl -X POST http://localhost:3000/api/playground/create -H "Content-Type: application/json" -d '{"language":"glsl"}'
3. Open the session URL in browser
4. Push an invalid shader: curl -X POST http://localhost:3000/api/playground/<sessionId>/update -H "Content-Type: application/json" -d '{"fragmentSource": "void main() { INVALID SYNTAX }"}'
5. Canvas goes black, browser console shows THREE.WebGLProgram: Shader Error
6. Check errors: curl http://localhost:3000/api/playground/<sessionId>/errors → {"errors":[],"structuredErrors":[]}

Impact

• MCP get_errors tool is effectively broken for GLSL — agents can never see compilation errors
• update_shader returns compilationErrors: [] even for invalid shaders
• The error bar in the playground UI never appears for compile errors
• Agents have no feedback loop when iterating on shaders

Proposed Fix

Instead of checking gl.CURRENT_PROGRAM, access Three.js's internal diagnostics after the test render. Options:

1. Use renderer.info.programs to find the program for our material and check its diagnostics
2. Listen for Three.js onError callback on the ShaderMaterial
3. Check gl.getError() after render and scrape the WebGL shader log from the attached shaders on the material's program
4. Use material.program after the first render — Three.js stores the compiled program on the material, which gives access to shader objects even when compilation failed

Option 4 is likely simplest:

renderer.render(scene, camera)

// After render, Three.js attaches the program to the material
const program = (material as any).program
if (program) {
  const gl = renderer.getContext()
  const glProgram = program.program  // the underlying WebGLProgram
  // ... existing error checking code against glProgram
}

Also need to handle the case where program is null (Three.js may not create it at all on severe errors) by catching the console error or using renderer.debug.onShaderError.

File

apps/web/src/components/playground/PlaygroundCanvas.tsx:150-220