Per-protocol capability profiles: overriding a model's protocol should re-derive inferred capabilities

Follow-up to #61 (Databricks native APIs), which documents this limitation in memory-bank/aiConfig.md.

Problem

Protocol-stamping providers (LiteLLM, and now Databricks) infer a model's capabilities for the protocol they stamp. A natively-routed Databricks Claude model advertises thinkingEffortLevels and PDF input because the anthropic-messages route supports them; the same endpoint forced onto openai-chat (via a user protocol override or a connection-level protocol) does not support those capabilities — but it keeps the stamped ones.

The generic fix ("mask capabilities when final protocol ≠ stamp") was considered and withdrawn during planning: resolveModels merges user capability overrides into the flat model object before attachRouting, so a pipeline mask cannot distinguish user-supplied capability values from inferred ones, and no safe protocol-keyed mask exists post-merge.

Proposed direction

Introduce a provenance/profile seam in the resolution pipeline: carry inferred capabilities as a per-protocol profile (or tag capability values with their provenance — inferred vs user override) so that when the final resolved protocol differs from the discovery stamp, inferred capabilities can be re-derived for the actual route while user overrides still win.

Scope notes

• Pre-existing limitation for LiteLLM; Databricks native routing widens the surface.
• Related: a profile-key transport through chat params (separate issue) could share the same seam.

Read memory-bank/aiConfig.md, then trace the resolveModels and attachRouting stages described in the issue. Determine how inferred capabilities can retain protocol provenance while user overrides remain authoritative; done means a protocol override re-derives stamped capabilities for the final route without discarding explicit user values.