fix(desktop) type declarations for getContext on raw desktop backend

[Giesch]

This updates the declared types on getContext to match the way they're used in the documentation (returning a GPUCanvasContext for contextId: "webgpu").

Fixes #36214
I used Claude Code while working on this PR

Edited (2026-08-01):

This PR also adds new () construct signatures to the GPUCanvasContext and
ImageBitmapRenderingContext constructor objects, so instanceof type checks and narrows.
Without a construct signature, x instanceof GPUCanvasContext raises TS2359; the alternative
Function & { prototype: X } clears TS2359 but narrows to {} rather than X. This is a
second, independent type-level fix that also benefits OffscreenCanvas users. The construct
signature is documented as not being a supported way to create a context.

[bartlomieju]

Checked this against the implementation and the current canary — the change is correct and the test is meaningful:

• The overloads match the runtime exactly: UnsafeWindowSurface::get_context (ext/canvas/byow.rs:211) dispatches on exactly bitmaprenderer and webgpu, returns Ok(None) for anything else, and also returns None when a different context was already created — so | null on both overloads is right.
• The new () additions are genuinely required, not incidental. With only { prototype: X }, TS raises TS2359 ("right-hand side of an instanceof must be assignable to Function"), and the plausible alternative Function & { prototype: X } clears TS2359 but narrows to {} instead of X. new () is also what lib.dom.d.ts does for every non-constructible interface, and there's in-repo precedent (new (): GPUError, cli/tsc/dts/lib.deno_webgpu.d.ts:1621).
• I ran the new main.ts against the unpatched 2.9.3 libs: 6 errors, including the getContext assignability ones. So it does fail before and pass after.

A few things worth tightening:

1. The new () additions contradict the doc comments directly above them. lib.deno_canvas.d.ts:246 says a GPUCanvasContext "is obtained from OffscreenCanvas.getContext … rather than constructed directly", same for ImageBitmapRenderingContext. Since the construct signature is needed for instanceof, keep it — but reword those comments (or note that the signature exists only so instanceof narrows), otherwise someone will later "fix" one or the other.

Related, and out of scope for this PR: on canary 2.9.3 new GPUCanvasContext() and new ImageBitmapRenderingContext() currently succeed and hand back an uninitialized object. Per spec these should be illegal constructors (Chrome throws). So the new signature isn't lying today, but it will be once the runtime adds a webidl.illegalConstructor guard — probably deserves its own issue.

2. Mirror the null-returning overload from OffscreenCanvas. lib.deno_canvas.d.ts:310 already documents the ids Deno doesn't implement:

// Spec also defines "2d", "webgl", and "webgl2" context ids; Deno does
// not implement those and getContext returns null for them.
getContext(contextId: "2d" | "webgl" | "webgl2", options?: any): null;

The runtime behaves identically for UnsafeWindowSurface (byow.rs:222, _ => return Ok(None)), and the goal here is to mirror the OffscreenCanvas overloads — so adding that third overload (plus the /** Get a drawing context… */ doc) would make the two declarations actually match.

3. assertType only checks assignability, so it under-constrains. assertType<OffscreenRenderingContext | null>(surface.getContext(contextId)) passes for any narrower return type too. A strict-equality helper would pin the exact types — and, more usefully, lock the overload order, which is the easiest thing to break later:

type Equals<A, B> = (<T>() => T extends A ? 1 : 2) extends
  (<T>() => T extends B ? 1 : 2) ? true : false;

Not blocking — the test as written does catch the regression.

4. Nit: "exitCode": 0 in __test__.jsonc is the default and can be dropped.

Scope: the new () change is a second, independent fix (it affects OffscreenCanvas users too), but it's small and directly motivated by the test, so I wouldn't split it. Could you add a sentence about the instanceof fix to the PR description, though, so it isn't a surprise for reviewers and the changelog?