Feature: Add `MaxAttachments` field to Model struct

[iceymoss]

Description

Problem

Some AI providers enforce hard per-request limits on the number of image attachments. For example, Google Gemini caps at 10 images per request. Currently there is no way to express this limit in Catwalk's Model struct, so downstream consumers (like Crush) have to hard-code these limits on their side.

This creates several issues:

• Fragile defaults: Limits are maintained in consumer code (e.g. a hard-coded map[InferenceProvider]int), requiring a consumer release to update when providers change limits
• Wrong granularity: Limits are per-provider but should be per-model (e.g. gemini-2.5-flash may have a different limit than gemini-2.5-pro)
• No discoverability: Consumers can't programmatically determine a model's attachment limit — they have to maintain their own lookup tables
• No override path: Users who know their model supports more (or fewer) attachments than the default have no standard way to configure it

Proposal

Add a MaxAttachments field to the Model struct:

type Model struct {
    ID                     string       `json:"id"`
    Name                   string       `json:"name"`
    // ... existing fields ...
    SupportsImages         bool         `json:"supports_attachments"`
    MaxAttachments         int          `json:"max_attachments,omitempty"` // NEW
    Options                ModelOptions `json:"options,omitzero"`
}

Semantics

• 0 (zero / omitted): no hard limit (rely on context window limits instead)
• > 0: maximum number of image attachments allowed in a single request to this model

Known limits

Provider	Model	Limit	Notes
Gemini	All models	10	Google docs
Vertex AI	All Gemini models	10	Same as Gemini
Anthropic	All models	—	No hard limit (context window governs)
OpenAI	All models	—	No hard limit (context window governs)

Benefits

• Single source of truth: Model definitions in Catwalk carry their own attachment limits
• Per-model granularity: Different models from the same provider can have different limits
• Consumer simplification: Downstream projects can read model.MaxAttachments instead of maintaining their own lookup tables
• User overrides work naturally: Users already override model fields like context_window and max_tokens in their config — max_attachments follows the same pattern

Related

• Crush PR that prompted this: fix(agent): prune excess images from history to prevent session deadlock crush#2613
• Crush issue: Chat becomes unusable after exceeding image limit crush#2604