fix(ci): align Azure OIDC trust with renamed immutable repository identity

[cristim]

Summary

Azure Sanity fails before running its tests after the repository identity changed to LeanerCloud/reserved-instances-cli with immutable OIDC subjects enabled. This blocks normal merging of PR LeanerCloud/cloud-commitments-cli#1889; no check bypass is authorized.

Observed evidence

• Exact PR head: 2b0310847db4232d0c7e28133c3ac1893a15fbf1.
• Failed run: https://github.com/LeanerCloud/reserved-instances-cli/actions/runs/35037134858
• Azure Login reports AADSTS700213, no matching federated identity record for repo:LeanerCloud@86753534/reserved-instances-cli@1106317010:pull_request.
• Read-only GitHub actions/oidc/customization/sub response: use_default: true, use_immutable_subject: true, prefix repo:LeanerCloud@86753534/reserved-instances-cli@1106317010.
• Read-only inspection of the cudly-terraform-deploy application shows its PR and main credentials still use repo:LeanerCloud/CUDly:pull_request and repo:LeanerCloud/CUDly:ref:refs/heads/main. A legacy feature-branch credential also uses the old repository name. No cloud state has been changed.

Reproduction and expected behavior

The Azure Sanity PR workflow receives the new GitHub subject and fails at login, before Build + Run Azure sanity. Its existing issuer and audience are https://token.actions.githubusercontent.com and api://AzureADTokenExchange.

Expected: the intended CI identity accepts the current repository's exact scoped subjects, without broadening issuer, audience or resource permissions, and the sanity tests run successfully. Main-branch trust needs checking before merging so the subsequent deployment is not stranded. Main deployment failure has not been exercised in this investigation.

Proposed fix and boundary

After explicit operator approval, verify the application's client ID against the configured CI identity and update the bootstrap-managed PR/main federated subjects to match current GitHub claims. Preserve scope and have a rollback to the prior subject values. Keep the Terraform source in terraform/environments/azure/ci-cd-permissions/sp.tf and associated configuration consistent with the actual trust; current expressions at lines39-58 use the old name-only subject format. Do not disable immutable subjects or skip Azure Sanity to make CI green.

Re-run failed Azure Sanity on the same head after the authorized trust correction. Require all other exact-head CI, substantive CodeRabbit review and independent local review before merge. The bootstrap module is privileged/manual by project policy; this report does not authorize its application.

Severity: high, urgency now, internal shipping impact. Found while following PR LeanerCloud/cloud-commitments-cli#1889; tracked separately from its audit-log changes.

[cristim]

Coordination update requested by the user: the cudly-split session owns the broader rename/split plan at /Users/cristi/Dropbox_Maestral/devel/cudly-split (CODEX-BRIEF.md, HANDOVER.md, PLAN.md). Its intended destinations are cloud-commitments-{cli,go,mcp,platform}, with current PRs drained before module normalization and carving. This OIDC blocker must be aligned with that plan, including future platform deployment and go sanity identities; no standalone trust change or Terraform apply has been performed here. A coordination request with current live evidence was posted to the shared agent message bus. Earlier successful deployment run conclusions do not establish that the current PR OIDC subject is trusted; the present Azure login failure and live old-subject credentials are the relevant evidence.

[cristim]

Duplicate of #2

This issue's ask ("verify the application's client ID against the
configured CI identity and update the bootstrap-managed PR/main federated
subjects to match current GitHub claims... keep the Terraform source in
terraform/environments/azure/ci-cd-permissions/sp.tf and associated
configuration consistent with the actual trust") describes exactly the same
defect and the same fix as #2 in this repo: the live Azure (and AWS/GCP)
OIDC trust still names an identity the repository no longer has, and the fix
is to re-derive the federated-credential subjects from the repository's
current claims and re-apply the bootstrap module.

The repo-identity mismatch this issue hit (reserved-instances-cli /
immutable-subject rename, evidenced against
LeanerCloud/reserved-instances-cli at the time) and the repo-split rename
this issue's own comment flags (cloud-commitments-platform, coordinated
via the cudly-split session's plan) are two instances of the same root
cause: GitHub's sub/repository claims follow the repository's current
name, and this repo's federated credentials are keyed on a name rather than
an immutable id. #2's fix direction is specifically to make the trust
rename-proof (repository_id/repository_owner_id for AWS/Azure,
attribute.repository_id for GCP) rather than re-keying it to today's name
only to have the next rename repeat this same incident. Re-keying to
cloud-commitments-platform without that would fix today's break and leave
the exact same class of failure for the next rename.

This issue's own text already anticipates the merge: "This OIDC blocker must
be aligned with [the cudly-split] plan, including future platform deployment
and go sanity identities; no standalone trust change or Terraform apply has
been performed here."

#90 (also in this repo) is the adjacent, narrower fix already landed: it
removes the Azure pull_request-subject federated credential entirely
(unused now that PR sanity checks moved to cloud-commitments-go), rather
than trying to re-key it. That leaves #2 as the sole remaining tracker for
the rename-proof re-key + bootstrap re-apply this issue asks for.

Closing as a duplicate of #2. If the immutable-subject / AADSTS700213
failure mode described here needs distinct evidence preserved (e.g. the
specific use_immutable_subject: true prefix format), that's captured
in this issue's history for whoever picks up #2 to reference.