Enhanced Azure Repos accounts and binding commands

[mjcheetham]

Refs: git-ecosystem#2057

Summary

Builds on the IMicrosoftAuthentication reshape (#22 — msauth-newapi → new-protocol) to deliver the first user-visible feature it unlocks: a clearer Microsoft account model for Azure Repos.

Today the Azure Repos provider conflates "which Microsoft identities does GCM have credentials for" with "which identity should I use for this organization". Both layers live in the same AzureReposBindingManager, both are keyed by UPN, and neither is directly inspectable. This PR splits the two concerns:

• Accounts: identities GCM holds Microsoft credentials for. Source of truth is the MSAL cache. New azure-repos login / logout / list commands manage this pool directly, mirroring gh auth login / az login vocabulary.
• Bindings: pure preferences saying "for this scope, prefer this account". The binding manager itself trafficks in IMicrosoftAccount, storing the MSAL HomeAccountId (stable across UPN renames) and the UPN side-by-side under a new scope union (Tenant / Org × IsLocal). Resolution layers most-specific-first.

With the underlying API now speaking in IMicrosoftAccount end-to-end (from the prerequisite PR), the binding manager can pass account records straight through to msauth — no UPN ↔ HomeAccountId translation glue at the provider boundary.

No protocol-layer features (state[] retry loops, prompt-and-remember pickers) are wired up in this PR — that's the next layer. This is the data model and verb surface they'll build on.

What's in this PR

Three commits, ordered as a readable story.

1. azrepos: migrate to IMicrosoftAccount and drop the obsolete msauth extension
   The Azure Repos OAuth path is the only production caller of the now-obsolete string userName overload of GetTokenForUserAsync in the tree, so migrate it and delete the obsolete extension in the same commit. GetAzureAccessTokenAsync constructs an IMicrosoftAccount from the resolved UPN (or null when no UPN was resolved) and passes it to the new interface overload directly; with the caller migrated, MicrosoftAuthenticationExtensions has no remaining users and disappears. The interface is now the single shape callers talk to, with no parallel API to drift against.

2. azrepos: add login/logout/list for Microsoft accounts and rename list to list-bindings
   Splits the verb surface into two clusters:

   • login [--tenant <id|domain>], logout (<account> | --all), list — operate on the MSAL account pool only. They do not touch the binding manager. login defaults to the organizations authority (work/school account picker); --tenant exists primarily to pre-stage a guest-account record when the home tenant differs from the tenant you want to use it for.
   • bind, unbind, list-bindings — manage which account a particular ADO tenant or org should use. list-bindings is what list used to be (pure rename of the binding view).

   The names were previously overloaded: the old list showed bindings, there was no equivalent of gh auth status, and signing in or out was an implicit side effect of bind/unbind. Splitting matches the vocabulary of comparable tools (az login, gh auth login).

3. azrepos: rebuild binding manager around scopes and home account id
   The marquee commit. The pre-rewrite binding manager had one stored shape — (orgName, userName) — and one verb pair to manipulate it. It could not distinguish "use account A for any org in tenant T" from "use account A for org O", and the stored value was a UPN, so a rename outside GCM silently broke the binding.

   Rebuild around:

   • Scope union. AzureReposBindingScope is a sealed discriminated union of Tenant(id) and Org(name), each carrying an IsLocal flag that picks per-clone vs. machine-wide storage. Resolution is most-specific-first: local Org → global Org → local Tenant → global Tenant → nothing.
   • IMicrosoftAccount-typed API. The manager takes IMicrosoftAccount on Bind and returns one from GetAccount, so the storage boundary owns the UPN-vs-HomeAccountId distinction and the provider doesn't have to encode-then-translate at the cache boundary.
   • Dual-key storage. .accountid always holds the MSAL HomeAccountId, .username always holds the UPN. Both are written atomically when both are known; either alone when only one is available. Legacy .username-only bindings from older releases continue to read back as a UPN-only account and migrate to the new shape on the next rewrite. No format detection on write, no drift warning on read — with atomic dual-key writes both keys present is the normal, fully-resolved state.
   • MicrosoftAccount.FromIdentifier factory. New public API on MicrosoftAccount (Core) that classifies a single user-typed string into the matching slot: an Entra <object-id>.<tenant-id-guid> shape (split on the last ., mirroring Microsoft.Identity.Client.AccountId.ParseFromString, with only the tenant-id side required to be a GUID) lands in HomeAccountId; anything else (UPNs, bare words, ADFS-style single tokens) lands in UserName. Used everywhere the provider previously had to decide which slot a raw string belongs in — CLI bind, URL/credential username on get, and store cache-miss fallback all go through the same factory.

   bind/unbind are reshaped: bind <account> (--tenant <id> | --org <name>) [--local] and unbind (--tenant <id> | --org <name>) [--local]. <account> is matched against the MSAL cache by either UPN or HomeAccountId; on a cache miss the value is classified by MicrosoftAccount.FromIdentifier and persisted as-is, so a clone can be pinned to a specific MSAL account by either UPN or HomeAccountId. The NoInherit sentinel from the old manager is dropped — with bindings now resolved by an explicit hierarchy, a per-clone "always prompt" toggle is better delivered through a future picker UI than as a magic empty string.

   Credential get/store/erase paths integrate with the new resolver; list-bindings learns to group under scope-derived headings (dev.azure.com/<org>, login.microsoftonline.com/<tenant-id>). Tests cover the new storage shape (HomeAccountId-only, UPN-only, and both fields), legacy .username-only fallback at both Tenant and Org scopes, scope/level resolution precedence, the FromIdentifier factory (classic Entra GUID.GUID, non-GUID object id, ambiguous-as-UPN, malformed-tenant rejection, null/whitespace rejection), and a new DevAzureUrlHomeAccountId GetCredentialAsync test pinning the URL-user classification.

What this enables (deliberately not in this PR)

Each of these belongs in a follow-up PR that ships a concrete user-visible win on top of this foundation:

• Account picker UI.
  Avalonia + terminal fallback for the multi-candidate case (when more than one cached account matches the request's tenant, or none does and the user needs to pick or sign in). The new account-pool surface is where the picker reads its options from.

• State-aware get + prompt-and-remember + optimistic auto-route.
  Now that state[] and continue are live (from the underlying new-protocol PR), the AzRepos provider can return a token optimistically (e.g. the only cached account in the request's tenant), record which account it tried in state, and pick a different one on a 401 — escaping the "wrong cached account is the only candidate" trap that a naive single-match auto-route would create. The picker grows a "remember this choice" checkbox whose result is threaded through state and persisted on the next store — so a binding is only written when the chosen credential actually worked.

• Friendly tenant names.
  Today list-bindings shows raw tenant GUIDs under the login.microsoftonline.com/<id> heading. A Graph-based lookup can map those to display names; deferred until there's a clear cache story.

Compatibility

• Existing .username bindings from older releases.
  Read transparently as a fallback when no .accountid exists at the same scope (Org and Tenant scopes — the legacy storage was Org-only in older releases, but the fallback is symmetric now). The first time a binding is rewritten (via bind, or implicitly via store), it migrates to .accountid keyed by HomeAccountId.

• Existing bind <org> <username> CLI syntax.
  Breaking. bind and unbind now take --tenant/--org/--local flags and a single positional <account>. The old positional <organization> <username> form is gone. vnext is still pre-release and the verb surface needed to align with the new identity model; a deprecation period would have lived in an awkward shape.

• azure-repos list output.
  Breaking. list now shows MSAL-cached accounts; the binding view moved to list-bindings. Scripts parsing the old format need to switch verb.

• MicrosoftAuthenticationExtensions deletion.
  Out-of-tree callers that depended on the obsolete string userName overload of GetTokenForUserAsync (added in the prerequisite PR) now need to construct an IMicrosoftAccount. The in-tree migration and deletion happen together in commit 1.

Testing

• Full unit test suite passes (Core, AzureRepos, GitHub, Bitbucket, GitLab) — 1322 tests, 0 failures.
• New test coverage for the binding manager: HomeAccountId-only, UPN-only, and dual-field bind shapes; legacy .username-only read fallback at both Tenant and Org scopes; local-vs-global enumeration boundaries; and the layered resolution hierarchy across scopes and levels.
• New test coverage for MicrosoftAccount.FromIdentifier in Core: classic Entra (GUID.GUID), non-GUID object id (B2C / multi-dot shapes), ambiguous-as-UPN cases, malformed-tenant rejection, and null/whitespace rejection.
• AzureReposHostProviderTests updated to the new mock surface (GetAccount(scope) returning IMicrosoftAccount), with a new DevAzureUrlHomeAccountId test pinning the URL-user classification.
• Manually smoke-tested azure-repos list against a live MSAL cache with multiple accounts.

Notes for reviewers

• Reviewing commit-by-commit is recommended. The chain is deliberately ordered so each commit tells one story; the squashed diff hides the consumer-migration → product-change progression.
• Each commit builds cleanly and tests pass at every step.
• The binding manager's "no translation helpers" property is the headline cleanliness win. The previous draft of this work had a TranslateUpnToAccountIdAsync / TranslateAccountIdToUpnAsync pair gluing the binding store to the auth API; with msauth taking IMicrosoftAccount natively (from the prerequisite PR) those helpers don't exist.
• MicrosoftAccount.FromIdentifier is the one new piece of Core (non-AzRepos) public surface introduced by this PR. It exists because three sites in the AzRepos provider need to classify a single string into the right IMicrosoftAccount slot; consolidating the heuristic on the type that owns the two slots keeps the provider out of the classification business and gives follow-up consumers (eg. the account picker UI) one place to reuse.

Builds on #22. Closes part of git-ecosystem#2057.