[Fix] Verify Azure DevOps Entra credentials and explain rejected ones

[daniel-lxs]

Problem

The Azure DevOps Microsoft Entra paths (service principal and delegated) had no guidance about required API permissions and no validation. Both modes request the .default scope, so Entra issues a token for whatever the app registration was already consented for: a registration with no Azure DevOps access authenticates fine, saves cleanly, and then every call fails at repository sync with a bare 401 Unauthorized.

What this PR does

Validates credentials at save time. Saving entra or delegated config makes one real Azure DevOps call (the same repository listing the sync uses) before anything is persisted. A credential that cannot reach the organization fails the save with actionable text; nothing is written. PAT validation goes through the same probe. Only definitive rejections (203/401/403) fail the save; an unverifiable result such as a network error still saves, matching existing PAT behavior.

Explains rejections. Azure DevOps API errors now carry their HTTP status and the provider's own explanation from the response body. A rejected credential surfaces as a short toast: a brief lead-in, the provider's message with GUID chains collapsed, then one action sentence. The same message replaces the raw 401 Unauthorized on sync failures.

Names the required permissions. Both Entra modes in setup and in Settings now name the required Azure DevOps API permissions (Code, Graph, and User Delegation / Impersonation) plus the save and admin-consent steps, with a link to a new "Required API permissions" section in the docs. The permission list lives in one shared constant so UI and docs cannot drift.

Screenshots

Service principal mode: permissions hint with a Setup guide link

Delegated mode: connected account, same hint

Rejected save: the provider's own diagnosis plus one action

Testing

• Verified against a live Azure DevOps organization: a service principal without organization access is rejected at save with the TF401444 explanation and nothing persisted; the delegated flow (connect, probe, save, sync, service hooks) succeeds as a Basic-access user; the PAT probe returns valid.
• Unit coverage in packages/ado and the source-control command tests, including a regression test for deployments configured through runtime env vars, where the form submits blank values.
• pnpm lint, pnpm check-types, and the full pnpm test suite pass.

🤖 Generated with Claude Code

[roomote-roomote]

No code issues found. See task

• packages/ado/src/api.ts:1027 Transient Microsoft Entra token-endpoint failures still block saving: this catch converts network, timeout, and 5xx failures to invalid, which assertValidSourceControlConfigInput rejects. Return unknown for unverifiable failures, reserving invalid for definitive credential rejection.
• packages/ado/src/api.ts:1079 A transient delegated-token refresh failure also blocks saving: resolveAdoDelegatedToken throws for token-endpoint network and 5xx failures, and this catch converts every error to invalid. Return unknown for unverifiable refresh failures (and apply the validation timeout to the refresh request), reserving invalid for a definitive rejected or expired delegated connection.

_{Reviewed 9c5f3fd}