[P0][CONN-04] Connector health, permissions and partner access

Programme: #1
Epic: #18

## Objective
Treat real provider access, schema drift, quotas, legal restrictions and operational ownership as part of feature readiness—not external paperwork hidden behind an integration logo.

## Scope
- Capability support matrix: prototype / sandbox / supervised / production / unavailable.
- Track provider application approvals, scopes, commercial terms, ToS, caching/redistribution and automation restrictions.
- Schema/API-version monitoring and drift canaries.
- Rate-limit/quota telemetry, retry-after behavior and backoff policy.
- Production test accounts and low-risk canary operations.
- Named owner and escalation path per connector.
- Sunset/deprecation workflow and truthful Original-view fallback.

## Product rules
- Do not market an operation as supported until the production route and required permissions are actually available.
- Read support does not imply write/checkout/bid support.
- Brittle extraction paths have separate reliability/support status from official APIs.

## Acceptance criteria
- [ ] Every advertised connector capability has a live-access record, conformance result and owner.
- [ ] Rate limits and schema/API changes create visible degraded state rather than data corruption.
- [ ] Provider revocation/deprecation can disable capability dispatch centrally.
- [ ] Cache/redistribution restrictions are enforceable by the connector/data layer.
- [ ] Canary failures automatically prevent unsafe promotion where configured.
- [ ] Product support matrix distinguishes API, MCP/WebMCP, DOM and visual-fallback paths.

## Dependencies
- CONN-01

**First phase:** P0
**Maturity target:** P7
**Owner:** connectors-domains

## Task issues
- [ ] #395 `CONN-04.T01` — Create operation-level access and support inventory
- [ ] #396 `CONN-04.T02` — Begin partner and rights review work
- [ ] #397 `CONN-04.T03` — Integrate health and support status with the runtime
- [ ] #398 `CONN-04.T04` — Implement schema and API drift canaries
- [ ] #399 `CONN-04.T05` — Implement quota, retry-after and backoff policy
- [ ] #400 `CONN-04.T06` — Create safe production canary and sunset operations
- [ ] #401 `CONN-04.T07` — Gate advertised support and ownership

Start by reading dependency CONN-01 and the task issues #395–#401, beginning with #395's operation-level access and support inventory. Map the connector health, permissions, drift, quota, canary, sunset, and support-matrix requirements across those tasks. Done means the listed acceptance criteria are implemented and each advertised capability has live-access, conformance, ownership, and safe-dispatch status.

Written by the indexing model from the issue text.