feat(account): add Azure & GitHub OAuth sign-in and cross-fork PRs + Big Perf optimisations

[t1gu1]

Summary

This PR introduces a major overhaul of the Pull Request workflow and repository management, focusing on GitHub OAuth integration, cross-fork support, Azure DevOps compatibility, and
significant performance optimizations.

🔐 GitHub OAuth & Tokenless Workflow

• Sign in with GitHub: New device-flow authentication in Settings > Accounts.
• Keychain Security: Tokens are stored in the OS keychain and never exposed to the frontend.
• REST-based PR Path: Activates a new tokenless REST path that removes the requirement for the gh CLI for core PR actions (listing, creation, merging, etc.).
• Cross-Fork Support: Seamlessly handles PRs between forks and their upstream repositories, including listing and creation.

🏢 Azure DevOps Integration

• Full Lifecycle Support: New AzureProvider for PR listing, creation, merging, and checkout.
• Rich Features: Support for PR comments, CI check status (branch-policy evaluations), and reviewer votes/reviews.
• Auto-Refresh: Implemented automatic access token refresh for uninterrupted workflows.

⚡ Performance & Responsiveness

• PR Cache (SWR): Disk-persisted "Stale-While-Revalidate" cache for PR lists and details. The UI now paints instantly using cached data while revalidating in the background.
• Async Backend: Converted Tauri commands to async, offloading blocking Git and network operations to background threads to prevent UI freezes.
• libgit2 Fast Path: Optimized git_status using in-process libgit2, significantly reducing IPC overhead compared to spawning CLI processes.

🎨 UI/UX Enhancements

• Standardized Avatars: Centralized avatar styling for a consistent "disk" look across all views.
• Enhanced Status Visibility: Integrated CI check status directly into the sidebar's "waiting dot".
• Smart Link Handling: External Markdown links now open in the system browser rather than the app webview.
• Fluid Loading: Replaced manual refresh buttons with automatic spinners during background data fetches.

🛠 Other Improvements

• GH CLI Guidance: Automatically guides users to account settings when gh CLI auth errors are detected.
• Standardized "Open in Browser" labels and icons across all forge providers.
• Optimized PR data loading to reduce redundant API calls.

---

!! IMPORTANT !!

For that PR i use a Github Client ID that i created to make the github auth works.
But it should the yours/the gitwand project.

Simply go here https://github.com/settings/developers and click on the top right button New Oauth App.
Be sure to have the ---> device flow enabled <---
Then use the given CLIENT ID instead of the one that i used.

---

Kinda the same thing with Azure

Go to: https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade

Steps:

1. Name it (e.g. "GitWand").
2. Supported account types → Accounts in any organizational directory (multi-tenant — matches organizations endpoint in code).
3. Register. Copy Application (client) ID = your GITWAND_AZURE_CLIENT_ID.
4. Left nav → Authentication → Allow public client flows = Yes (required for device flow). Save.

Why

• Don't love to have to install gh and configure it (Less pain with oauth for the user)
• The possibility to create and see fork PRs for a project is a game changing for contributors (me)
• Azure was a missing platform/forge use a lot by entreprises
• The app was kinda slow when we changed of context (The optimization part)

PRs is so a nice feature but without the forks functionality, i could not use it. :(

Test plan

• Sign in with GitHub from Settings and confirm the account persists.
• Open the PR view from a forked repo and verify the target selector defaults to upstream.
• Create a same-repo PR and confirm no regression.
• Verify the new UI strings render in each supported locale.

Tests that i didn't do (If you have these in your setup, could be nice if you test it)

• Create a cross-fork PR via both the REST and gh code paths. (Edit: I got some time to test it and add some fixes ✅ )
• Test the changes with GitLab
• Test changes with BitBucket

Notes:

• I dont try back when authenticated with gh (Edit: Done ✅ )
• I dont test with the other services like Gitlab and Bitbucket
• This PR request was made from GitWand from the fork! ✅

How it looks

Here the icon change from github to Azure (I fix it for every platforms)

PRs comments

---

⚙️ Enterprise prerequisites (maintainer note)

Hands-on testing surfaced two org-policy gates that are not bugs but must be
documented, since the stated target for this feature is enterprises. In locked-down
tenants the OAuth/device-flow sign-in will be blocked until the org pre-approves the
GitWand app:

• GitHub — OAuth App access restrictions. If the organization that owns the repo
  has third-party OAuth app restrictions enabled, authenticated calls return
  403 ("the <org> organization has enabled OAuth App access restrictions") even
  with a valid token. An org owner must approve the GitWand OAuth app
  (Org → Settings → Third-party Access → OAuth app policy), or the user must request
  approval. Personal repos and unrestricted orgs work out of the box.

• Azure DevOps / Entra ID — admin consent. If the tenant disables user consent
  for third-party apps (and/or enforces app governance / Conditional Access), the
  device-flow sign-in hits the admin-consent wall and a standard user cannot complete
  it. A tenant admin must grant admin consent for the GitWand Entra app
  (Azure Portal → App registrations → GitWand → API permissions → "Grant admin
  consent"), or approve it through app governance. We request the narrow
  user_impersonation delegated scope (rather than .default) so a standard user can
  self-consent wherever the tenant allows it.

TL;DR for enterprise rollout: an org/tenant admin should pre-approve the GitWand
GitHub OAuth app and the GitWand Entra app once; after that, users sign in normally.

[t1gu1]

I fix some issue that i found.

• When we clicked on a PR description link, it was open inside Gitwand instead of a browser.
• Diff changes were not display correctly in the PRs list
• Performance was not crazy when trying to see PRs and PR detail (And no caching)
• Profile icons was not using the new style

[t1gu1]

There is a new big change on performance side that change everything.
The app feels way faster and reactive now!

It offload blocking commands to background threads

At first, it was for the PRs but it was feeling way too nice to not extend it to all the app.

---

Example:

Move long-running Tauri commands (Azure API calls, Git operations) to background threads using tauri::async_runtime::spawn_blocking. This prevents UI freezes during blocking network or process I/O, maintaining application responsiveness.

A related change prevents loadMorePrs from firing duplicate pagination requests during SWR revalidation, avoiding redundant slow API calls.

---

It is more than 174 commands converted from sync fn → async fn across every command file.

Added to that, we added some cache on PRs to makes it feels even more reactive.
Still sync while seeing it. (We see some loading indicators)

[t1gu1]

@devlint Huge PR here, but a lot of news and tweaks around PRs and a lot of optimizations!

This is a really nice PR that unlocks PRs functionalities for other platforms, forks and makes it globally more accessible.

Don't forget to read the "!! IMPORTANT !!" section of the first comment where you should take a time to replace some public CLIENT ID keys. (I mean it works with the current keys, but i think you should own these to be able to manage it more)

[devlint]

Review + hands-on testing

Thanks for this — it's a big, well-structured contribution and the code is
unusually well-commented. I pulled it locally and exercised the GitHub path
end-to-end; Azure I couldn't fully test (see below). Summary of what I found.

✅ Verified working

• New Rust modules (github_api.rs, azure.rs) compile clean (incremental,
  through branch switches).
• GitHub OAuth device flow works end-to-end → token stored in the OS keychain
  (gitwand:github/oauth), never logged, never returned to the frontend. 👍
• REST routing activates correctly once the keychain token is present; the PR
  list populates via rest_list_prs (title, author, branch→base, state, CI dot).

🔴 Blockers before merge

1. Default OAuth client_id ships the author's personal app.
   github_api.rs falls back to Ov23licwiCpPiRPRodWN and azure.rs to the
   Azure CLI's well-known id. As written, every user who doesn't set
   GITWAND_GH_CLIENT_ID authenticates against the author's app. Worse, the
   "not configured" guard tests cid.starts_with("REPLACE_WITH"), which never
   matches the real default → dead code. Need GitWand-owned OAuth/Entra apps
   baked via env at build time, and a guard that actually fires.
2. Bearer token passed as a curl process argument (-H "Authorization: Bearer …") in both github_api.rs and azure.rs. This violates the
   AGENTS.md rule "tokens must never appear in spawned process arguments" — on
   macOS/Linux the token is visible via ps for the request's duration. Pipe
   the header via curl --config - (stdin) instead.

🐛 Confirmed by testing

3. Cross-fork PRs always show +0 / -0. rest_list_prs computes diff stats
   via git diff --numstat origin/base...origin/head, but a fork PR's head
   branch isn't in origin, so numstat returns 0. Ironically this breaks
   exactly for the cross-fork PRs that are this PR's headline feature (every PR
   in a fork-based repo reads 0/0). Suggest pulling additions/deletions from
   the REST API (GET /pulls/{n}) instead of local numstat.
4. Azure in locked-down enterprise tenants. The device flow requests
   .default, which triggers admin consent; in a tenant with user-consent
   disabled + third-party-app governance, sign-in is blocked outright. Since the
   stated target is enterprises, this needs documenting as a prerequisite (IT
   must pre-approve the GitWand app). A narrower delegated scope
   (user_impersonation) reduces friction where the tenant allows user consent.

🟠 Worth addressing

• New parsing surface has no unit tests: parse_azure_remote (5 URL
  shapes), owner_repo, rollup_from_check_runs, dedupe_checks are pure and
  critical — easy regressions, please add tests.
• Async inconsistency: azure.rs wraps blocking work in spawn_blocking,
  but gh.rs/github_api.rs run blocking curl/git directly inside async fn (occupies Tokio workers). Worth unifying.
• git fetch origin on every first-page list load is a real network cost under
  the SWR cache revalidation.

[devlint]

Maintainer follow-up — pushed 6 commits

I pushed the following on top of 1fda453 (maintainer edits enabled), addressing
the review blockers and the issues found while testing locally. CI test target now
compiles and passes (35 unit tests green).

Commit	What
21fc473	Own OAuth client IDs + Azure scope. Default GitHub OAuth and Entra client IDs switched to the GitWand-owned apps (were the author's personal app / the Azure CLI's well-known id). Azure now requests the user_impersonation delegated scope instead of .default, so a standard user can consent without a tenant admin where the tenant allows it.
b6abdad	Remove dead client_id guard. The cid.starts_with("REPLACE_WITH") "not configured" check was unreachable once the default is a real client_id — dropped it.
a34da98	Keep OAuth secrets off argv. Bearer access tokens (github_api.rs + azure.rs) and Entra form secrets (refresh_token, device_code) were passed as -H / --data-urlencode arguments, exposing them to ps. They now go through a curl --config - file read from stdin. Verified end-to-end (a 403 org-restriction response confirms the token is still transmitted).
585b27f	Fix +0/-0 on cross-fork PRs. rest_list_prs computed diff stats from a local git diff --numstat origin/base...origin/head, but a fork PR's head branch isn't in origin, so every cross-fork PR read 0/0. Now fetched from the REST per-PR detail endpoint (GitHub computes it server-side), in parallel per PR; also drops the per-list git fetch origin. Verified in-app — real counts now render.
9696552	Unbreak cargo test. check_remote_reachable was made async but its two unit tests still called .unwrap() on the future, so the lib-test target failed to compile. Block on the future in the tests.
a00c06a	Tests for the new parsing surface. 22 unit tests covering the pure, regression-prone helpers: parse_azure_remote (all 5 remote URL shapes), urlenc, with_api_version, auth_failed, dedupe_checks, rollup_from_checks/rollup_from_check_runs precedence, json_to_pr, map_comment, map_policy_status, map_vote, bearer_config.

I also documented the enterprise prerequisites (GitHub OAuth App access restrictions /
Azure admin consent) in the PR description.

Still open (not addressed here)

• Async consistency: gh.rs / github_api.rs run blocking curl/git directly
  inside async fn, whereas azure.rs wraps them in spawn_blocking. Not a UI-freeze
  bug (these run off the webview thread), but worth unifying — left for a follow-up since
  it touches ~15 command signatures.

[devlint]

Requesting changes to gate the merge until the items below are settled. Solid,
genuinely useful work overall — most blockers are already resolved by the commits
I pushed (maintainer edits), but I'd like these confirmed/closed first.

Resolved on the branch (please review my commits)

• Own GitHub/Entra OAuth client IDs + Azure user_impersonation scope (21fc473)
• Dead REPLACE_WITH client_id guard removed (b6abdad)
• OAuth secrets moved off argv → curl --config - via stdin (a34da98)
• Cross-fork +0/-0 fixed via REST per-PR stats (585b27f)
• cargo test unbroken + 22 parsing unit tests added (9696552, a00c06a)

Please address before merge

1. Confirm the pushed edits read correctly to you, especially the client-id
   change and the stdin-secret refactor.
2. Async consistency: gh.rs / github_api.rs run blocking curl/git
   directly inside async fn, while azure.rs uses spawn_blocking. Either
   unify on spawn_blocking or add a comment explicitly deferring it to a
   tracked follow-up.
3. CI green on the new commits (test target now compiles).
4. Enterprise prerequisites are documented in the description (GitHub OAuth
   App restrictions / Azure admin consent) — please sanity-check the wording.

Optional but recommended: the bitbucket REST path still passes its token on
argv; worth the same stdin treatment for consistency.