Fast Path Pipeline: RBAC fixes (foundation)

Part of #557

## Problem

Two RBAC gaps cause deploy failures after the pipeline runs:

1. **Namespace annotation fails (F3):** When the deploy workflow tries to annotate the namespace and deployments, it fails with `User does not have access to the resource in Azure` because the pipeline's workload identity doesn't have `AKS RBAC Writer`. Today we only assign this role when `azureRbacEnabled` is detected on the cluster, but pipeline identities always need write access for annotations.

2. **Image pull fails (F1):** After the workflow successfully builds and pushes an image to ACR, pods fail with `ImagePullBackOff` because the AKS node pool's kubelet identity doesn't have `AcrPull` on the ACR. We assign `AcrPush` to the *pipeline* identity for building, but never grant pull access to the *kubelet* identity that actually runs the pods.

## Changes

- Add `isPipeline` flag to `IdentityRoleContext` — when true, always include `AKS RBAC Writer` regardless of cluster RBAC detection
- Wire `isPipeline: true` through `ensureIdentityWithRoles` for the GitHub pipeline flow
- Add `getKubeletIdentityObjectId()` — resolves the kubelet identity from `az aks show`
- Assign `AcrPull` to the kubelet identity on the ACR scope during pipeline identity setup
- Keep `continue-on-error: true` on workflow annotation steps as a safety net

Trace IdentityRoleContext and ensureIdentityWithRoles through the GitHub pipeline flow, then inspect the workflow annotation steps. Use az aks show to verify how the kubelet identity is resolved. Done means pipeline identities receive AKS RBAC Writer, kubelet identities receive AcrPull on the ACR scope, and annotation steps retain their safety net.

Written by the indexing model from the issue text.