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

Look at the custom-extension form and configuration storage logic, likely in a module handling MCP (Model Context Protocol) extensions. Identify where HTTP headers are currently stored. Review the existing secret store integration for environment variables. The work involves designing a migration for existing headers, creating a mechanism to classify and mask sensitive headers, and ensuring safe secret lifecycle management. Testing must cover various scenarios like mixed headers and failed writes.

Vom Indexierungsmodell aus dem Issue-Text verfasst.