Reuse pi's built-in model catalog instead of hardcoded Foundry model capabilities

[1openwindow]

Problem

src/adapters/pi-rpc.mjs registers a custom foundry provider with hardcoded
model capabilities (pi-rpc.mjs:255-270). These values just re-implement pi's
own defaults, and they suppress the real capabilities of known models. Every
deployed model is forced to reasoning:false / 128k / text-only, so e.g. o3
loses reasoning and gpt-4.1 loses its 1M context window.

Key finding

pi already ships an authoritative model catalog
(@earendil-works/pi-ai/dist/models.generated.js), including the built-in
azure-openai-responses provider with correct metadata:

model	contextWindow	maxTokens	reasoning	input
gpt-4.1	1047576	32768	false	[text, image]
gpt-4o	128000	16384	false	[text, image]
o3	200000	100000	true	[text, image]
gpt-5.1	400000	128000	true	[text, image]

models.json supports overriding a built-in provider's baseUrl/apiKey
without redefining its models (pi docs/models.md -> "Overriding Built-in
Providers"). All built-in models and capabilities are preserved.

Proposed change (Option A)

Stop writing a custom foundry provider with hardcoded caps. Instead override
the built-in azure-openai-responses provider's baseUrl + apiKey and let pi
supply model capabilities from its own catalog.

Tier 1 - known models (default, zero config): deployment name matches a
catalog id -> pi uses correct caps automatically (o3 reasoning, gpt-4.1 1M window,
multimodal).

Tier 2 - unknown deployment names: fall back to a minimal custom model entry
(omit caps, let pi default them) with optional user modelOverrides for
correction. Runtime stays silent in both tiers.

Scope of work

• src/adapters/pi-rpc.mjs: override built-in azure-openai-responses
  (baseUrl + apiKey only, drop the hardcoded models array).
• .agents/skills/pi-foundry/scripts/configure-env.mjs: PI_ARGS
--provider foundry -> --provider azure-openai-responses.
• Verify the correct api type matches the endpoint
  (azure-openai-responses vs the current openai-responses).
• Confirm keyless managed-identity auth (apiKey: "!<token cmd>") still attaches
  to the overridden built-in provider.
• Update test/contract.test.mjs accordingly.

Out of scope

• models.dev - not adopted; pi already ships an equivalent catalog.
• Multi-model / name-mapping - only single-model capability config.

Note

Image pins @earendil-works/pi-coding-agent@0.76.0 (Dockerfile.runtime); local
dev is 0.78.0. Version-drift alignment to be discussed separately after this
issue is filed.