aspire do push to an existing container registry requires a full provisioning context and silently creates a resource group

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

When the only Azure resource a pipeline step touches is an **existing** container registry
(`AddAzureContainerRegistry(...).PublishAsExistingInResourceGroup(name, rg, subscription)` —
the new 13.5 API), `aspire do push` still runs `create-provisioning-context`, which:

1. **Hard-requires `Azure:SubscriptionId`** — fails with
`Aspire.Hosting.Azure.MissingConfigurationException: An Azure subscription id is required. Set the Azure:SubscriptionId configuration value.`
2. **Hard-requires `Azure:Location`** — fails with
`MissingConfigurationException: An azure location/region is required. Set the Azure:Location configuration value.`
3. With both set but **`Azure:ResourceGroup` unset, it invents a default name and CREATES the
resource group** (`rg-aspire-apphost`) in the subscription as a side effect — even though
nothing in the push provisions into it. The pipeline reports success; the empty resource
group is left behind.

None of these values are meaningfully used by the push itself: `provision-acr` resolves the
existing registry from its own annotation (which already carries name, resource group, and
subscription), `login-to-acr-*` logs into it, and the images push there. The provisioning
context's subscription/location/resource group exist only to satisfy the context step.

This matters for CI: a build agent whose only job is "build images and push them to an existing
registry" must be given a workload subscription, a location, and a resource group name — and if
the resource group value is omitted (a natural simplification, since the push doesn't use it),
every CI run silently creates `rg-aspire-apphost` in the workload subscription.

### Expected Behavior

Pushing images to an existing registry should need, at most, the registry reference itself.
Specifically, one or both of:

- `create-provisioning-context` should not demand `Azure:SubscriptionId` / `Azure:Location`
when every Azure resource reachable from the target step is marked existing; and/or
- resource-group materialization should be deferred until a step actually provisions a resource
into it, rather than happening eagerly during context creation.

At minimum, creating a resource group as a side effect of *context creation* on a push-only
pipeline is surprising and deserves a warning or an opt-out.

### Steps To Reproduce

AppHost (publish mode):

```csharp
var builder = DistributedApplication.CreateBuilder(args);

var acr = builder.AddAzureContainerRegistry("acr")
.PublishAsExistingInResourceGroup(
builder.AddParameter("acr-name"),
builder.AddParameter("acr-resource-group"),
builder.AddParameter("acr-subscription-id"));

builder.AddAzureContainerAppEnvironment("env")
.WithAzureContainerRegistry(acr);

builder.AddProject("api");

builder.Build().Run();
```

Then (with an authenticated `az` login):

```bash
export Parameters__acr_name=
export Parameters__acr_resource_group=
export Parameters__acr_subscription_id=

# 1. No Azure:* at all -> MissingConfigurationException (subscription id)
aspire do create-provisioning-context --non-interactive

# 2. Azure__SubscriptionId set -> MissingConfigurationException (location)
export Azure__SubscriptionId=
aspire do create-provisioning-context --non-interactive

# 3. Azure__Location also set, Azure__ResourceGroup unset -> succeeds AND creates
# an empty resource group named rg-aspire-apphost in
export Azure__Location=
aspire do create-provisioning-context --non-interactive
az group show --subscription -n rg-aspire-apphost
```

### Exceptions (if any)

```
Aspire.Hosting.Azure.MissingConfigurationException: An Azure subscription id is required. Set the Azure:SubscriptionId configuration value.
(thrown by Aspire.Hosting.Azure.Provisioning.Internal.PublishModeProvisioningContextProvider, step 'create-provisioning-context')

Aspire.Hosting.Azure.MissingConfigurationException: An azure location/region is required. Set the Azure:Location configuration value.
```

### Aspire doctor output

- Aspire.AppHost.Sdk 13.5.0; Aspire.Hosting.Azure\* 13.5.0
- .NET SDK 10.0.400
- aspire CLI: 13.5.0+e076d8e427cb3afb528dbd605acd74c3aea69f94
- OS: Windows 11 (agent repro also on ubuntu-latest)

### Anything else?

Related: #7514 (cross-subscription existing resources — `PublishAsExistingInResourceGroup`
with a subscription otherwise works beautifully in 13.5; the emitted Bicep scopes both the
`existing` reference and the AcrPull role assignment with
`resourceGroup(, )`). This issue is only about the push-side
provisioning context around it.