## Why

AI provider management can store safe provider metadata, and plugin bridge contracts can request AI assistance by purpose. The missing piece is the platform-mediated invocation path: plugins and pages need AI help for reviewable recommendations without ever receiving raw provider keys, base URL credentials, or unmanaged model access.

## What Changes

- Add platform AI invocation domain, DTO, validator, service, and API behavior for purpose-scoped requests.
- Route requests through platform-owned provider configuration and mockable provider clients, with no real-key requirement for tests.
- Return bounded AI recommendations, usage metadata, and reviewable config diff suggestions instead of direct run-side writes.
- Add plugin bridge/SDK and frontend client integration for `ai.invoke` requests without exposing provider credentials.
- Add tests proving purpose enforcement, provider redaction, unsafe prompt/payload rejection, mock provider behavior, and no raw key exposure.

## Capabilities

### New Capabilities

- `platform-mediated-ai-invocation`: Platform-owned AI invocation for plugin and console workflows with purpose validation, credential isolation, bounded outputs, and reviewable recommendations.

### Modified Capabilities

- Builds on `ai-provider-management` and plugin bridge capabilities without adding raw provider access to plugins or platform_web.

## Impact

- Affects `platform/` AI invocation contracts, services, validators, APIs, and tests.
- Affects `platform_web/` API contracts/client and plugin bridge host behavior for AI requests.
- Affects `plugins/` SDK/example AI request helpers and tests.
- Does not require real provider keys/accounts, external paid services, live network calls in tests, billing, cloud host sales, or direct config writes.