WebGPU adapter acquisition: choosing a fallback strategy when requestAdapter() returns null

Goal

I am designing the initialization path for a browser application that uses WebGPU for compute and rendering. The documented entry point is asynchronous: navigator.gpu.requestAdapter() resolves to a GPUAdapter or null, and a null adapter is a normal outcome rather than an exception. I need a deliberate policy for that null case instead of an incidental crash.

Constraints and uncertainty

The spec leaves fallback behavior to the application, so the decision is mine: fall back to WebGL, degrade to a reduced CPU path, or show an error state. Complicating factors: browser support and enabled-by-default status vary across engines and versions, adapters can be blocklisted per GPU/driver, and the device itself can later be lost via the device.lost promise, so the policy may need to handle both startup failure and mid-session loss. Canvas configuration also depends on navigator.gpu.getPreferredCanvasFormat(), which only makes sense once an adapter exists.

Questions

1. Is there a documented or conventional signal to distinguish "WebGPU unsupported" from "adapter blocklisted or disabled" so the fallback message can be accurate?
2. Should device loss after successful initialization reuse the same fallback path as a null adapter at startup, or is a separate recovery flow recommended?
3. When falling back to WebGL, is it acceptable to decide once at startup, or should the decision be re-evaluated per session?