sandbox capture --calls` requires every user to hand-roll a canvas/WebGL call recorder

[gitickle]

wre sandbox capture --calls <FILE> is documented as "serves a recorded canvas and WebGL call list for the page to answer". #5 asked where that FILE comes from and, as far as I can tell, the answer today is: you write your own recorder. That seems at odds with the toolkit's premise — capture should be a wre command, not a per-user instrumentation project.

The gap

A property profile answers the questions you knew to ask. Sensors that draw — canvas/WebGL probes whose pixels get digested — are answered from the canvas table, which keys images under a digest of the drawing operations that produced them. The capture page records five stock drawings and one WebGL render. Anything outside that set falls through to default and records a miss — and against an enumerating sensor (a Shape F5 custom build is the motivating case) the misses are the fingerprint.

So a faithful profile for a given sensor needs a calls file recorded from a real session with that sensor running. Producing one currently means:

• hooking HTMLCanvasElement.prototype (getContext, toDataURL, toBlob) plus the width/height setters,
• wrapping every method on CanvasRenderingContext2D.prototype and WebGLRenderingContext/WebGL2RenderingContext.prototype,
• preserving arrival order and per-canvas handles,
• serializing arguments into the exact shapes collectGraphics's decodeArgument expects ({list, kind} for typed arrays, {imagedata} for ImageData, {extension} for extension requests),
• discovering all of the above by reading crates/wre-sandbox/assets/capture-graph.html, because none of it is documented.

That is a meaningful chunk of bespoke code every --calls user has to reinvent, against an internal schema that can drift under them without notice.

Suggestions

1. Ship the recorder. Either:
   • wre sandbox record-calls — serves (or injects via wre-cdp into a live Chrome) a hook that produces a valid calls file from a real browsing session; or
   • a capture mode that navigates the real target with the sensor live and harvests the drawing operations it performs — device profile and calls file in one pass, zero user instrumentation.
2. Document the file format where the CLI reference documents --calls: array or {calls|graphics} payload, handle = canvas<N>:<tail>, the special methods (size, getContext, toDataURL/toBlob, matchMedia, getVoices, canPlayType), and the argument encoding.