az containerapp registry set resets runtime configuration (breaks .NET data protection)

## Describe the bug

When using `az containerapp registry set` to add or update container registry credentials, the command unintentionally resets unrelated configuration properties in `properties.configuration`. Specifically, the `runtime` object (which contains .NET-specific settings like `runtime.dotnet.autoConfigureDataProtection`) is set to `null` after running the command.

This is a **breaking side effect** that disables critical .NET features like ASP.NET Core Data Protection for apps that scale to multiple replicas.

## Command causing the issue

```bash
az containerapp registry set \
--name \
--resource-group \
--server ghcr.io \
--username \
--password
```

## Steps to reproduce

1. Create or use an existing Container App with .NET runtime configuration enabled (the "Development stack" setting in Azure Portal set to ".NET")

2. Verify the runtime configuration exists before the change:
```bash
az containerapp show --name --resource-group --query "properties.configuration.runtime" --output json
```
**Output before**: `{}` or `{"dotnet": {"autoConfigureDataProtection": true}}`

3. Run the registry set command:
```bash
az containerapp registry set \
--name \
--resource-group \
--server ghcr.io \
--username MyUsername \
--password MyNewToken
```

4. Check the runtime configuration again:
```bash
az containerapp show --name --resource-group --query "properties.configuration.runtime" --output json
```
**Output after**: `null` (no output)

## Expected behavior

`az containerapp registry set` should **only** modify registry-related properties (`configuration.registries` and the associated secret), preserving all other configuration properties like:
- `runtime` (including .NET data protection settings)
- `ingress`
- `dapr`
- Any other unrelated configuration

## Actual behavior

The command appears to perform a JSON Merge Patch on the `configuration` object that only includes the `registries` array. Properties not explicitly included in the patch payload (like `runtime`) are reset to `null`.

## Impact

This bug has significant production impact:
- **ASP.NET Core Data Protection is silently disabled** - Apps using features like anti-forgery tokens, authentication, SignalR, Blazor Server, or session state will break when scaled to multiple replicas
- **No warning or indication** - The command completes successfully with no indication that other settings were modified
- **Silent data loss** - Configuration is lost without any way to recover it from the command output

## Environment

- **Azure CLI version**: 2.75.0
- **OS**: macOS (Darwin 24.6.0)
- **Shell**: zsh

```
$ az --version
azure-cli 2.75.0
core 2.75.0
telemetry 1.1.0
```

## Workaround

Instead of using `az containerapp registry set`, update only the secret value directly:

```bash
# Find the existing secret name referenced by the registry
az containerapp registry list --name --resource-group --query "[].passwordSecretRef" --output tsv

# Update only the secret value (does not affect other configuration)
az containerapp secret set \
--name \
--resource-group \
--secrets "="
```

This approach updates the credential without touching any other configuration.

## Suggested fix

The `az containerapp registry set` command should either:

1. **Read-modify-write pattern**: Fetch the current configuration, merge only the registry changes, then write back the complete configuration
2. **Use a more targeted API**: If the ARM API supports updating just the registries array without affecting other properties, use that
3. **Preserve existing properties**: Ensure the PATCH payload includes all existing configuration properties, not just the ones being modified

## Related

This affects the `.NET on Azure Container Apps` feature documented here:
https://learn.microsoft.com/en-us/azure/container-apps/dotnet-overview

The `autoConfigureDataProtection` setting is critical for .NET apps as described in the documentation:
> "In .NET 8.0.4 and later, ASP.NET Core apps that use data protection are automatically configured to keep protected data accessible to all replicas as the application scales."