Centralize model API capabilities and add Pi provider

[a-github-name]

Summary

• centralize API-facing model capabilities in typed managed-model catalog profiles
• project /v1/models, request validation, runtime selection, agent eligibility, setup, and Pi metadata from that catalog source of truth
• add an installable @mere-run/pi provider package validated against Pi 0.84.2
• preserve catalog-derived model metadata in the generated local Pi fallback provider
• update CLI guidance, README, changelog, and runtime/model-source documentation

Why

An OpenAI-compatible base URL and API key do not describe the behavior an agent harness needs. Pi also needs reliable task, tool-call, reasoning-level, modality, context/output-limit, and OpenAI dialect metadata. Those facts were previously split across engine switches and integration-specific model definitions, which allowed behavior to drift.

This refactor makes the managed-model catalog authoritative and lets runtime configuration overlay only effective limits. It also fixes an existing inference bug where Q35 OCR models could be treated as chat-serving models.

Impact

Pi can now discover compatible local models dynamically from mere.run's self-describing /v1/models response and configure each model without ID-based guessing. Other OpenAI-compatible clients keep the standard response fields and may ignore the additive metadata.

Uncataloged custom runtimes remain supported through a conservative compatibility fallback.

Validation

• ./scripts/check.sh
  • SwiftLint: 0 violations across 1,237 files
  • 2,833 tests executed, 206 skipped, 0 failures
  • complete CLI help and hygiene gate passed
• pnpm typecheck in integrations/pi
• pnpm test in integrations/pi: 4 passed
• pnpm pack --dry-run
• live Pi 0.84.2 mock-provider smoke: mere pi smoke ok