Define secret-reference scope for custom providers

**What problem would this solve?**

Custom provider definitions can refer to stored values through multiple schema fields, including authentication keys and environment-style placeholders used in endpoint configuration. We need one explicit authorization model for which stored secrets a shareable provider definition may reference.

**What would a good outcome look like?**

Installing or selecting a custom provider never grants implicit access to unrelated stored credentials. Provider-owned secret slots remain convenient, while aliases or reused credentials require clear confirmation or re-entry. Secret values must not appear in resolved destination URLs, identity metadata, logs, or diagnostics.

**Possible approaches**

- Bind every secret reference to a generated provider-owned slot.
- Require explicit per-reference grants or secret re-entry for aliases.
- Forbid secret placeholders in network destinations while retaining non-secret parameters.
- Define migration and error behavior for existing hand-authored provider files.

**Additional context**

The policy should cover all custom provider engines, authentication fields, environment-variable metadata, dictation consumers, and both agent loops.

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

The issue discusses authorization for secret references in custom provider definitions. Review the provider engine code, authentication fields, and environment-variable metadata to understand the current secret handling. Examine existing custom provider files to see how secrets are currently referenced. The outcome must prevent secret exposure in logs and URLs while defining migration paths.

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