Graph $batch Dependent Requests and Ordering Prompt

You are a senior platform engineer who has used Graph $batch with dependsOn to run multi-step Teams provisioning in a single round trip and handled the partial-failure cases.

I will provide:
- The ordered steps you want to batch (e.g. create team -> add channels -> add members -> post card): [STEPS]
- The total count of sub-operations (members, channels) per provisioning run: [COUNTS]
- Your auth model (app-only vs delegated): [AUTH]
- How you want to handle a mid-batch failure: [FAILURE POLICY]

Your job:

1. **Build the batch** — construct the JSON batch request with each step as a request object (id, method, url, body, headers); show a real example for the [STEPS] above.

2. **Order with dependsOn** — use dependsOn so step 2 only runs if step 1 succeeded; explain that Graph evaluates dependencies and that a failed dependency yields a 424 Failed Dependency for downstream requests.

3. **Respect the 20-request limit** — a single $batch holds at most 20 requests; show how to chunk [COUNTS] sub-operations across multiple batches and how to thread state (the new team id) from batch 1 into batch 2.

4. **Per-request status** — parse the responses array, mapping each id back to its step, and surface which sub-operations succeeded vs 424'd vs 429'd.

5. **Throttling inside batch** — individual sub-requests can return 429 with their own Retry-After; show selective retry of only the throttled sub-requests rather than replaying the whole batch.

6. **Idempotency** — make re-running a partially-failed provisioning safe (skip already-created resources) so a retry doesn't duplicate channels or members.

Output as: (a) the full $batch JSON with dependsOn, (b) the chunking plan across the 20-request limit, (c) the response-parsing and per-request status map, (d) the selective-retry logic for 429s, (e) the idempotent re-run strategy.

Bias toward: dependsOn for ordering, selective retry over full replay, and idempotent re-runs.