docs: correct and expand EUAP/canary region access onboarding

[Himanshu Bhushan (hbhushan3)]

https://redhat.atlassian.net/browse/AROSLSRE-1860

What

Adds an EUAP/Canary Region Access section to the INT/STG/PROD E2E subscription onboarding docs, covering Microsoft.Resources/EUAPParticipation, and corrects the existing AFEC flag guidance.

The doc previously stated:

PROD additionally requires InProgress to enable EUAP/canary region access.

That is not correct. Microsoft.RedHatOpenShift/InProgress only controls which RP instance ARM routes to. It does not grant the subscription access to the region itself.

Changes:

• Corrected the InProgress sentence and added an [!IMPORTANT] callout explaining the routing-vs-access distinction.
• Added a PROD (canary/EUAP regions only) row to the required-flags table.
• New section documenting the flag as ManualApprove (az feature register only reaches Pending), with a Step A–D flow: initiate → LionRock request (preferred) → Geneva Actions (fallback) → verify + az provider register.
• Documented the LionRock failure signature for non-1P subscriptions, and the fact that region access and quota are separate tracks.

Why

Without EUAPParticipation, resource group creation in eastus2euap fails with LocationNotAvailableForResourceGroup. Onboarding the two new PROD E2E subscriptions hit exactly this, and the gap in the docs cost roughly a month: the LionRock request auto-granted WAEAP approval (which reads like success), then quietly routed to manual RDQuota fulfillment, sat in Action Required, and was eventually backlogged with an unrelated "high demand for virtual machines in this region" message. The flag was never registered by that path.

For Red Hat tenant subscriptions this stall is the expected outcome rather than an exception, because Microsoft.RedHatOpenShift is not treated as in-scope 1P and the subs are handled as external. The section therefore keeps LionRock as the preferred first step but tells the reader what the stall looks like and when to escalate to Geneva Actions instead of waiting.

Testing

Documentation-only change; no code paths are affected, so no automated tests are included.

The documented procedure was executed end-to-end on 2026-08-21 against the two PROD E2E subscriptions and confirmed working — Microsoft.Resources/EUAPParticipation now reports Registered on both via the Geneva Actions fallback path described here.

Special notes for your reviewer

• The TM-AFEC group membership requirement in Step C is the part most likely to drift. Microsoft.Resources has not migrated to AFEC 2.0, which is the only reason that claim still auto-approves; if that changes, Step C needs revisiting. Called out in a [!NOTE].
• Anchor link #euapcanary-region-access is referenced from two places above the section — worth a quick check that it renders correctly.
• Microsoft-internal specifics (subscription IDs, RDQuota/ICM numbers, group ownership) are deliberately kept out of this public repo and tracked in the internal SOP instead.

PR Checklist

• PR is scoped to a single task (no mixed concerns)
• Title follows Conventional Commits format
• Summary explains the "Why" behind the change
• Linked to relevant ticket/issue
• Screenshots included (if graph/UI/metrics changes) — n/a
• Self-reviewed the diff
• CI/CD checks are passing (ignore Tide) — pending
• Draft PR used for WIP (if applicable)
• Commit history is clean (rebased/squashed)
• Tricky code blocks are commented — n/a, prose only
• Specific reviewers tagged — pending
• All comment threads resolved before merge

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hbhushan3

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• docs/OWNERS [hbhushan3]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment