Prompt attachment capability introspection

[brandonbloom]

ACP v1 advertises broad prompt-content support such as image, audio, and embedded context, but a client cannot determine whether a concrete attachment is usable before attempting delivery.

For a prompt-content realization, clients need an optional capability declaration for:

• accepted MIME types or patterns;
• maximum item count, decoded bytes per item, and aggregate decoded bytes;
• image dimensions and any declared resizing or transcoding behavior;
• model- or mode-specific constraints; and
• whether rejection occurred during client-side validation or later in the agent, model, or service.

Without this, an interoperable client must impose conservative local limits and treat provider-side rejections as late execution failures. It also cannot distinguish syntactically supported content from a known unsupported media type.

This proposal does not require every agent to advertise every limit. Absent information must remain unknown rather than being treated as an allowance. The shape could be a structured extension of promptCapabilities or a separately negotiated capability; the essential property is that declarations are per realization and do not make hidden uploads, conversions, or fallback behavior implicit.

Related work: #1559 proposes image-capability metadata for backend-advertised image limits. This discussion asks for a general prompt-attachment capability model that can include that image work while covering embedded resources, resource links, and the eager-versus-lazy failure boundary.

Concrete client use case: a reproducible evaluation harness needs to reject an image, PDF, or generic resource before inference when the selected agent cannot faithfully realize it, while recording a later service limit failure distinctly when the agent could not declare that ceiling.