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