Arc machine RG and AKS cluster RG must match (hard-coded in v0.1.0)

Hi team, first off — thanks for v0.1.0. We've been putting the agent through a 3-node Raspberry Pi 5 rack as the edge tier for an AKS cluster (part of an edge-tolerance demo), and wanted to share a few observations from the journey. Apologies if any of these are already known or have workarounds we missed.

## What we observed

In Arc mode the installer seems to look up the target AKS cluster in the same resource group as the Arc machine. In `pkg/arc/arc_installer.go` we noticed:

```go
clusterRG := arcConfig.ResourceGroup
```

In our test the Arc machine lived in `rg-edge` and the cluster lived in `rg-aks`, and `listClusterAdminCredentials` returned 404 because the agent looked for the cluster in `rg-edge`. Moving the Arc machine into the same RG worked around it.

## Impact for our scenario

Several customer topologies we're prototyping for (retail, manufacturing) keep edge devices in a per-site or per-region RG and the managed-service control plane in a separate platform-team RG, mainly for blast-radius, RBAC scoping, billing and lifecycle reasons. Putting them in one RG is a tough conversation, so we wanted to flag this early.

## One possible direction

Would it be feasible to add an explicit `targetCluster.resourceGroup` (and optionally `targetCluster.subscriptionID`) to the agent config, defaulting to the Arc machine's RG/sub for backward compatibility? Happy to test a prototype on the Pi rack if useful.

Version tested: v0.1.0 (git 65d8d38, build 2026-05-22).

---

## Other observations from the same Pi-rack edge demo

- #183 — Agent should preflight RBAC permissions before `assignRBACRoles`
- #184 — Hostname casing not normalized; PascalCase machine names fail node validation
- #185 — Kubelet MI exec credential does not propagate Arc HIMDS env vars
- #186 — `validateExclusiveAuthSettings` treats Arc and bootstrap-token as mutually exclusive
- #187 — Agent could auto-mint kubelet bootstrap-token when Arc/MI/SP credentials are available
- #188 — `kube1` systemd-nspawn launcher passes `--network-veth` but actually shares host netns

Start in pkg/arc/arc_installer.go and trace listClusterAdminCredentials, where clusterRG is currently taken from arcConfig.ResourceGroup. Review the agent configuration path and make the target cluster resource group, and optionally subscription, explicit while preserving the same-resource-group behavior; verify both same-RG and separate-RG scenarios.

Written by the indexing model from the issue text.