Upstream image_processing: route the saver by an explicit format argument, not the destination extension

## What we're trying to optimize

The cell's transform operations write their output to a staged scratch path, and scratch names carry no extension. ImageProcessing picks its saver from the destination path's extension, so `Transforming#perform` must encode to a suffixed sibling (`Output#path(extension:)`) and rename it into place (`Output#adopt`). That is a naming hoop and a rename syscall per transform, done only to smuggle the output format to the saver through the filename.

## What happens today

`pipeline.call(destination:)` hands the path to the toolchain, and the toolchain picks the saver from the path's extension — libvips dispatches `write_to_file` on the suffix, and `magick` infers the output format from the output filename. `convert(format)` only names the tempfile extension when ImageProcessing creates its own tempfile. With an explicit destination, the filename wins.

## Proposed upstream change

An explicit format/extension argument on `call` that defaults to the destination's file name when absent. It must be additive: some users rely on the destination extension winning over `convert`. The change is clean on both backends, inside ImageProcessing where its saver defaults already live:

- vips: ruby-vips has `write_to_target`, which takes the format hint as an argument separate from the filename. ImageProcessing can route through it and keep its own quality, strip, and format defaults.
- MiniMagick: ImageMagick accepts an explicit output format as a `PNG:/path` prefix on the output filename. One string change.

## Payoff

For hotcell: it removes the suffixed-sibling dance and one rename on the transform path. That is modest, since `Output#adopt` stays either way — pdftoppm names its own output and still needs it. The general case is stronger: anyone writing to an extensionless path (content-addressed names, descriptor-backed paths) hits this wart.

## Action

File an issue on [janko/image_processing](https://github.com/janko/image_processing) describing the use case, then follow with a pull request once the maintainer reacts.

Start with Transforming#perform, Output#path(extension:), Output#adopt, and pipeline.call(destination:); trace how convert(format) and each backend choose the saver. File the use case on janko/image_processing first, then follow with a pull request after maintainer feedback; the requested additive format argument and extensionless-path behavior define done.

Written by the indexing model from the issue text.