docs(#347): cache_ttl wording — MC's own deferral gate, not provider cache control

cache_ttl decides how long Magic Context ASSUMES a provider's cached prefix
stays valid; it has no effect on the provider's actual cache lifetime. The
previous wording ('matches most providers', 'Cache TTL' unqualified, 'never
expires (always-warm lane)') composed into a wrong mental model that the
setting controls the provider's cache.

Reword all three surfaces the issue names plus the TUI/Pi status twins:
- CONFIGURATION.md: 'matches most providers' -> states it is MC's own
  deferral gate and does not change the provider's cache lifetime; the
  default 5m matches Anthropic's default TTL. The 'never' sentinel now says
  MC never ASSUMES expiry, and notes provider-side extended TTL is a
  separate request-level concern (cache_control: { ttl }).
- magic-context.ts .describe(): leads with the scope (MC-side assumption,
  does not extend provider TTL) and qualifies 'never' as MC never assuming
  expiry for externally-kept-warm lanes.
- execute-status.ts / tui/index.tsx / tui-compiled / pi status-dialog:
  'never expires (always-warm lane)' -> 'never (MC never assumes expiry —
  external cache-keep)'.

Regenerated assets/magic-context.schema.json and the docs-site config
reference from the Zod schema (generator-owned). Updated the execute-status
test to assert the new wording. No rename of the key (breaking config
change); wording only.

Co-Authored-By: Alfonso <alfonso@cortexkit.io>