04-swarms: host is not granted Data Owner on the orchestrator group it creates (403 on orchestrator sandbox)

## Summary (revised)

Running 04-swarms after `setup.py` fails with `403 Forbidden` when the host creates the orchestrator sandbox. Root cause: the swarm creates its own fresh sandbox groups at runtime (`swarm-orch-*`, `swarm-workers-*`) and grants the orchestrator managed identity Data Owner on the worker group, but it never grants the signed-in host user any data-plane role on the orchestrator group. The host then calls `begin_create_sandbox` against that orchestrator group and gets 403.

Correction to the original framing: `setup.py` is NOT wrong about scope. The sandboxes docs (SDK quickstart and the sandbox-groups guide) assign "Container Apps SandboxGroup Data Owner" at the sandbox-group scope, and `setup.py` does exactly that for the `aca-sandboxes-samples` group. The gap is specific to 04-swarms and the extra groups it provisions.

## Repro

1. `az login`
2. `uv run python/samples/setup/setup.py --region eastus2`
3. `uv run python/samples/04-swarms/01-sandbox-inception/python/swarm.py`

Group provisioning and the RBAC grant to the orchestrator MI succeed, then:

```
azure.core.exceptions.ClientAuthenticationError: Operation returned an invalid status 'Forbidden'
```

at `begin_create_sandbox` for the orchestrator group.

## Recommended fix (docs-idiomatic)

Have the swarm grant the signed-in user "Container Apps SandboxGroup Data Owner" on the orchestrator group right after it creates that group, mirroring how it already grants the orchestrator MI on the worker group (per-group role assignment is the documented idiom). Apply the same to the CLI variant (`run.sh`) via `aca sandboxgroup role create --group ...`.

A coarser alternative is to grant Data Owner once at the resource-group scope so all child groups inherit. That makes the samples work, but it diverges from the docs, which assign at the per-group scope. Verified locally: an RG-scope grant lets 04-swarms run to completion (pi ~ 3.1421 across 4 workers), confirming the missing host grant is the cause.

Start with samples/04-swarms/01-sandbox-inception/python/swarm.py and inspect how the orchestrator and worker groups are created and assigned roles. Then read the CLI variant's run.sh and its sandbox-group role command. Done means the signed-in host can create the orchestrator sandbox without 403, while the existing worker and orchestrator flows still complete.

Written by the indexing model from the issue text.