[Feature] Make Azure Key Vault health check behavior configurable

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

The Azure Key Vault integration (Aspire.Azure.Security.KeyVault) constructs its health check with hardcoded defaults. Two aspects of the health check's behavior are therefore fixed for every Aspire application:

The health check always probes a secret literally named AzureKeyVaultSecretsHealthCheck.
The health check never creates that secret if it is missing.
Both aspects are configurable in the underlying health check package, but the capability is not reachable through Aspire's settings or configuration.

This causes concrete problems:

1. Conflicts with organizational secret naming policies.
Many organizations enforce naming conventions in Key Vault, such as required prefixes, environment or tenant segments, and restricted character sets. A fixed secret name cannot satisfy those conventions, so the secret either cannot be provisioned at all or the health check permanently reports unhealthy. There is no workaround short of bypassing the Aspire health check entirely.

2. No way to reuse an existing secret.
Applications that already depend on a known secret cannot point the health check at it. They must provision an additional secret whose sole purpose is to satisfy Aspire, which adds noise to the vault and to the provisioning pipeline.

3. No opt-in for automatic creation.
Some applications intentionally hold write permissions on their vault and would prefer the health check to self-provision its probe secret on first run. That behavior exists in the underlying package but cannot be enabled, so those users have to script the secret creation separately.

4. Least-privilege setups are penalized either way.
Users who deliberately grant read-only access cannot rename the probe secret to match what their platform team pre-provisioned. Users who deliberately grant write access cannot make use of it. The current fixed behavior serves neither group well.

### Describe the solution you'd like

Aspire should let applications influence the Key Vault health check's behavior, specifically which secret is probed and whether that secret may be created when absent, through the integration's settings and through appsettings.json, consistent with how other Key Vault settings are surfaced.

The important part is the capability and its reachability from configuration. The exact shape of the public API is a design decision I'd like maintainer input on, since it touches Aspire's public surface. In particular, whether these should be first-party primitives on the settings type or a direct pass-through of the underlying options type. The latter would pull a third-party type into Aspire's public API, which I assume is undesirable.

### Additional context

PR [#17949](https://github.com/microsoft/aspire/pull/17949) proposes one implementation of this. It has been open since June 5 with green CI and no maintainer review. I suspect the public API shape is the blocker rather than the feature itself, so this issue is meant to separate the two: get a decision on whether the capability is wanted, and if so, in what form.

I'm happy to adapt or resubmit the implementation once there is a direction.

Start by reviewing PR #17949 and the Azure Key Vault integration settings to understand the proposed public API. Compare the underlying health check options with the appsettings.json configuration path; done means a maintainer-approved design that exposes the secret name and missing-secret creation behavior through both settings and configuration.

Written by the indexing model from the issue text.