glass_screenshot has no way to bound its output size, and downscaling would need to keep the click coordinate space recoverable

[xxx]

ScreenshotArgs is {region, window_id} (crates/glass-mcp/src/params.rs:38). There is no
max_size, scale, format or quality parameter, and a grep of the capture path for
resize|downscale|thumbnail|scale_factor|max_dim|quality|jpeg finds nothing. A full-window capture
is encoded and returned at native resolution, whatever that is.

On a HiDPI or Retina display that is a large image, and the caller has no way to bound it short of
passing a smaller region — which changes what is captured, not how much it costs.

Why this is worth a knob

Bounding what a tool returns is otherwise something glass does deliberately:

• A11ySnapshotArgs.max_nodes has a default cap documented as protecting the token budget, 0
  lifts it, and a truncated walk says so.
• glass_logs has max_lines.
• glass_diff --include_image returns only the changed region rather than the whole frame.

glass_screenshot is the one output on the capture side with no bound at all, and it is the
largest single thing glass returns.

Design note: this changes the coordinate space

glass_click takes window-relative pixels, so a downscaled screenshot no longer maps 1:1 to click
coordinates. A naive max_size would quietly break pixel-driving for exactly the canvas/no-a11y
apps that depend on it most.

So whatever shape this takes must make the scale recoverable — return the applied scale factor (and
the source dimensions) in the result, so a caller reading a point off the image can convert back.
Silently returning a smaller image with no way to know it was scaled would be worse than the
current behaviour.

Possible shape

• max_size: bound on the longest edge; downscale before encode when the capture exceeds it.
• Result carries the applied scale and the pre-scale dimensions.
• Omitted means current behaviour, or a default cap — worth deciding which, in the same spirit as
  max_nodes's default cap.