Store MCP authorization headers outside plaintext configuration

**What problem would this solve?**
The custom-extension form stores environment-variable values through the secret store, but persists HTTP header values directly in the ordinary extension configuration. Users can reasonably paste a reusable bearer or API credential into an Authorization-style header, leaving it exposed in plaintext configuration, backups, exports, or diagnostics even though the runtime already supports secret-variable substitution.

**What would a good outcome look like?**
Classify credential-bearing extension headers, store their values in the platform secret store, and persist only an indirection. Editing must show a masked value without accidentally clearing or re-saving it as plaintext. Define migration for existing configurations, deterministic collision-safe secret naming or server-owned identifiers, and cleanup when an extension or header is removed. Non-sensitive headers should remain easy to edit inline.

The verification plan should cover: new and edited Authorization headers; mixed sensitive/non-sensitive headers; an existing `${VAR}` reference; secret-name collisions; rename/delete lifecycle; failed keyring writes; configuration export/diagnostics; and migration without sending or logging the raw value.

**Possible approaches**
- Treat well-known authorization header names as secret fields and generate opaque server-owned secret references.
- Add an explicit per-header “store as secret” control, defaulted on for credential-like names.
- Move extension credentials into a typed backend-owned credential object rather than encoding secret names in user-controlled environment keys.

**Additional context**
The runtime already expands secret references in headers; the design work is primarily safe capture, identity, migration, masking, and lifecycle management.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

Examinez la logique du formulaire d’extensions personnalisées et du stockage de la configuration, probablement dans un module qui gère les extensions MCP (Model Context Protocol). Identifiez où les en-têtes HTTP sont actuellement stockés. Examinez l’intégration existante du gestionnaire de secrets pour les variables d’environnement. Le travail consiste à concevoir une migration pour les en-têtes existants, à créer un mécanisme permettant de classer et de masquer les en-têtes sensibles, et à garantir une gestion sûre du cycle de vie des secrets. Les tests doivent couvrir différents scénarios, notamment les en-têtes mixtes et les écritures échouées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.