Replace the picture of an image widget

Replaces the picture of an image widget that already exists, with the same rules /v1/widgets/create-image applies to the file: at most 716800 bytes decoded, really a JPEG, a PNG or a GIF, and the new width and height read off the picture.

IT REPLACES THE PICTURE AND NOTHING ELSE. The name, the row, the column and the section of the widget stay as they are: a rename is /v1/widgets/rename and a move is /v1/widgets/move. No cached result is dropped, because an image is never executed against a provider.

THE PREVIOUS FILE IS NOT KEPT. A backup mirrors the DEFINITION of a widget and an image has none, so the only way back is uploading the previous picture again; the answer carries a before saying what the one it replaced measured and weighed.

A report built on a template is refused with 400 APPEND_NOT_ALLOWED, reason template_based: the product makes a copy per derived report of a text block and of an Excel or Sheets widget and of nothing else, so every picture such a report shows belongs to its template.

Refusals: 400 for the framework and the body, 400 INVALID_VALUE, 400 APPEND_NOT_ALLOWED, 403 WRITE_ACCESS_DISABLED, 404 NOT_FOUND, 409 SECTION_BUSY, 409 REPORT_IN_TRASH and 413 PAYLOAD_TOO_LARGE.

Every write endpoint reads dry_run and idempotency_key; see the Write guarantees section of the introduction.

A file that is refused is 400 INVALID_VALUE with the rule that stopped it in details.reason, one of: too_large (over 716800 decoded bytes), too_many_pixels (the header announces more than 25000000 pixels, which is a picture nothing draws and a decode nothing should pay for), format_not_supported (the first bytes are not a JPEG, a PNG or a GIF, whatever the file is called) and not_an_image (the bytes announce a format and do not decode as one).