ADO ↔ GitHub Integration: Pipeline Status Monitoring

## Problem Statement

The ACN scheduled release workflow (and future automation) needs to monitor Azure DevOps pipeline status from GitHub Actions. Currently, there's no authenticated path from GitHub → ADO API for the `msazure/One` project.

## Use Cases

1. **Scheduled release workflow** — After tag creation, monitor ACN PR Pipeline and CNI Release Test completion
2. **Future automation** — Any GitHub workflow that needs to know if an ADO pipeline passed/failed
3. **PR gating** — Could enable GitHub merge queue to wait for ADO pipeline results

## Options Explored

| # | Approach | Status |
|---|----------|--------|
| 1 | OIDC SP → ADO API (direct polling) | ❌ Blocked — needs ADO org admin to add SP |
| 2 | ADO → GitHub bridge (GitHub App posts statuses) | ✅ Proven on fork — recommended short-term |
| 3 | PAT-based auth | ❌ Rejected — 5-day expiry, not viable |
| 4 | Reuse Build Validations SP | ❌ Rejected — overscoped (full sub access) |
| 5 | Migrate ADO tests to GH workflows | 🔮 Long-term — eliminates auth problem entirely |

## Recommended: Option 2 (ADO → GitHub Bridge)

**Architecture:**
```
Tag push → ADO auto-triggers pipeline (native service connection)
→ ADO pipeline posts "pending" commit status to GitHub (via GitHub App)
→ ADO pipeline finishes → posts "success"/"failure" to GitHub
→ GitHub workflow polls: gh api commits//statuses
→ No ADO API access needed from GitHub side
```

**Steps:**
1. Create GitHub App with `statuses:write` on `Azure/azure-container-networking`
2. Add App ID + private key as secret variables in ADO pipelines
3. Add status-posting steps to `.pipelines/pipeline.yaml` and `.pipelines/cni/pipeline.yaml`
4. Update scheduled release workflow to poll GitHub commit statuses

**Security:** Low risk — App only has `statuses:write` (cosmetic), secrets live in ADO only, pipelines only trigger on protected refs.

**Precedent:** Same pattern used by `cilium-private` repo.

## Long-term: Option 5 (Migrate to GH Workflows)

Suggested by @QxBytes — if E2E tests ran as GitHub Actions workflows:
- `GITHUB_TOKEN` natively polls workflow status (zero auth setup)
- Tag push triggers workflows same as ADO
- Copilot agents work better with GH workflows
- Test workloads mainly interact with AKS clusters — portable

**Effort:** Large (rewrite pipeline YAML). **Timeline:** Weeks/months.

## ADO Pipeline Details

| Pipeline | File | Trigger |
|----------|------|---------|
| ACN PR Pipeline | `.pipelines/pipeline.yaml` | PR, merge queue, tags, nightly |
| CNI Release Test | `.pipelines/cni/pipeline.yaml` | Tags (`v*`, `dropgz/*`, `azure-ipam/*`) |
| GitHub Release | Def 393797 in `msazure/One` | Manual |

## Contacts

- **Build Validations SP owners:** @miguelgo, @QxBytes (John Payne)
- **ADO org:** `msazure`, Project: `One`
- **`acn-release-bot` SP:** App ID `75013c7b-3bea-441b-952c-e13d7c9247bc` (Object ID `29d8f13a-6ba6-4374-ad34-9cf875064d74`)

## Related

- PR #4410 — Scheduled release workflow (has `wait-pipeline` CLI ready for Option 1)
- Fork test run #28116621752 — Proves Option 2 polling pattern works

Start by reading .pipelines/pipeline.yaml, .pipelines/cni/pipeline.yaml, and the scheduled release workflow from PR #4410. Review the proven fork test run and the existing wait-pipeline CLI to understand status polling. Done means both ADO pipelines publish the documented GitHub commit statuses and the release workflow can observe their completion.

Written by the indexing model from the issue text.