Camera3d should fail loudly when used with the Canvas renderer

[obiot]

Problem

`Camera3d` (#1464) silently does the wrong thing under the Canvas renderer. Its perspective projection + depth-test-driven painter sort presuppose a WebGL context — the Canvas backend has no `gl`, no depth buffer, no `drawMesh` path. Today the engine just runs and produces a broken picture (no 3D, no mesh rendering, sometimes a blank canvas), with no error to tell the dev why.

Repro

```ts
const app = new Application(800, 600, {
renderer: video.CANVAS, // ← explicit Canvas
cameraClass: Camera3d, // ← Camera3d
});
```

→ no error, scene renders with no perspective, meshes invisible, depth-sort ineffective. User has no clue why.

Same thing happens when `video.AUTO` falls back to Canvas (WebGL unavailable / failIfMajorPerformanceCaveat = true on a low-perf device + Camera3d in the app's cameraClass).

Proposed

In the `Camera3d` constructor (or in `Application`'s camera-class instantiation path), check the active renderer at construction time and throw a clear error if it isn't a `WebGLRenderer`:

```ts
if (!(video.renderer instanceof WebGLRenderer)) {
throw new Error(
"Camera3d requires the WebGL renderer (Canvas backend lacks the " +
"depth buffer + 3D projection path Camera3d depends on). Set " +
"{ renderer: video.WEBGL } on your Application — or fall back to " +
"Camera2d if WebGL isn't available on the target device."
);
}
```

Fail-fast at construction time is better than a silently broken scene at runtime.

Open question

Should the check be on `Camera3d` itself (constructor-time, requires Camera3d to import the renderer class — possible circular dep) or on `Application` (which already mediates renderer + cameraClass)? Probably Application — cleaner separation, no new import in Camera3d.

Scope

• ~10 lines of code
• One regression spec: `new Application({ renderer: video.CANVAS, cameraClass: Camera3d })` must throw with a useful message
• CHANGELOG entry under `### Changed` (behavioural change — silent fallback → loud error)

Related

• feat(camera): Camera3d + Frustum + Stage/App cameraClass (19.7.0 PR B) #1464 (Camera3d initial PR)

[obiot]

Broadening this issue's scope — there's a related bug at the Application layer (one layer above Camera3d) where the silent-fallback should also fail loudly.

The Application-layer bug

`new Application(w, h, { renderer: video.WEBGL })` silently falls back to `CanvasRenderer` when WebGL is unavailable, instead of throwing. The chain:

• `application.ts` line 342-351 — both `AUTO` and `WEBGL` go through the same `autoDetectRenderer(this.settings)` path
• `autoDetectRenderer` (`autodetect.js`) wraps WebGL construction in try/catch and returns `new CanvasRenderer(options)` on any failure

So `renderer: video.WEBGL` today reads as "prefer WebGL, fall back to Canvas" — same as `AUTO`. The user has no way to express "I require WebGL, throw if unavailable". Yet `video.WEBGL` looks like exactly that contract.

Proposed split

Two distinct layers, two distinct failures:

Layer 1 — Application: `video.WEBGL` means required

```ts
// application.ts
switch (this.settings.renderer) {
case AUTO:
// "I want WebGL if available, Canvas otherwise."
this.renderer = autoDetectRenderer(this.settings);
break;
case WEBGL:
// "I require WebGL." Fail loudly.
if (!isWebGLSupported(this.settings)) {
throw new Error(
"Application: `renderer: video.WEBGL` was requested but the WebGL " +
"context could not be created (driver-blocklisted GPU, " +
"failIfMajorPerformanceCaveat: true on a software renderer, etc.). " +
"Use `video.AUTO` if Canvas fallback is acceptable, or check " +
"`device.isWebGLSupported()` before construction."
);
}
this.renderer = new WebGLRenderer(this.settings);
break;
default:
this.renderer = new CanvasRenderer(this.settings);
break;
}
```

Layer 2 — Camera3d: bail when active renderer isn't WebGL

(Original scope of this issue.) Defensive check in `Camera3d` constructor (or in `Application`'s camera-class instantiation path) that throws if `app.renderer` isn't a `WebGLRenderer`. Mostly redundant once Layer 1 lands — but covers the `video.AUTO` + `cameraClass: Camera3d` case where the user is fine with Canvas-fallback in general but explicitly asked for Camera3d, which can't run on Canvas.

Why both layers

• Layer 1 catches: "I asked for WebGL and the engine silently gave me something else." Generic — applies to ShaderEffect, Mesh, GPU tilemap, Light2d users too, not just Camera3d.
• Layer 2 catches: "I'm fine with AUTO fallback but I'm using Camera3d, which is WebGL-only." Specific to the 3D path.

Together they give a clear contract: explicit `video.WEBGL` → throw on failure; `AUTO` + `cameraClass: Camera3d` → throw if the AUTO chose Canvas.

Acceptance (updated)

• `new Application(w, h, { renderer: video.WEBGL })` throws when WebGL is unavailable (clear error message + suggested remediation)
• `Camera3d` (or `Application`'s camera-class wiring) throws when constructed under a `CanvasRenderer`
• A regression spec for each case
• CHANGELOG `### Changed` entry — behavioural change for users who relied on the silent fallback (probably nobody, but still a contract change)
• AfterBurner example doesn't need defensive `if (!app.renderer instanceof WebGLRenderer)` glue code on the user side once these throw at construction time

Status

I've drafted the Application-layer fix locally on `fix/video-webgl-no-silent-fallback` — small (~30 lines + test). Holding it pending consolidation under this issue rather than opening yet another PR.