An s3:// image sent to a model that refuses s3Location produces a request the backend rejects

[JGoutin]

Found while implementing #48, present in v1.15.0.

The per-model gate for s3Location covers documents only —
S3_LOCATION_DOCUMENT_SUPPORTED (stdapi/models/__init__.py:522, set to False for
Anthropic Claude in _anthropic_claude.py:257). Images have no equivalent gate, so
an s3:// image is always emitted as source.s3Location.

Anthropic Claude rejects that outright — verbatim from a real call:
This model doesn't support the s3Uri field. Remove s3Uri and try again. Mistral
Pixtral Large rejects it for images too, while accepting the same image inline. Of
the three families probed, only Amazon Nova accepted an image by reference.

So a request naming an s3:// image against Claude or Pixtral fails today, and the
failure is in a request we built — the user did nothing wrong.

Its own fix: commit rather than folded into #48.

[JGoutin]

Status: fixed forward on the 1.16 branch, not cherry-pickable

2cc3753c replaces the documents-only boolean gate (S3_LOCATION_DOCUMENT_SUPPORTED)
with a per-media-kind set (S3_LOCATION_MEDIA_TYPES) that is empty by default, so
a reference is only ever sent to a model measured to accept it for that kind. An
s3:// image to Claude or Pixtral is now downloaded and embedded instead of being
sent as an s3Location the model refuses.

For 1.15.1 this needs a minimal fix authored against v1.15.0. The forward fix
is the redesign, so there is no separable hunk to cherry-pick — the patch-release
version should be the narrow one: gate images the same way documents already are.