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).

カスタム拡張機能のフォームと設定ストレージのロジックを確認してください。おそらく MCP (Model Context Protocol) 拡張機能を処理するモジュールにあります。HTTP ヘッダーが現在どこに保存されているかを特定してください。環境変数向けの既存のシークレットストア統合を確認してください。この作業では、既存のヘッダーの移行を設計し、機密性の高いヘッダーを分類してマスクする仕組みを作成し、安全なシークレットのライフサイクル管理を確実にする必要があります。テストでは、混在したヘッダーや書き込みに失敗した場合など、さまざまなシナリオを網羅する必要があります。

索引モデルが issue の本文から書いたものです。