fix: prevent Git credential overwrite when authorizing a second account of the same provider [INS-3035]

[pavkout]

Summary

Authorizing a second, different account for the same Git provider (e.g. a
second GitHub account) silently overwrote the first credential instead of
adding a new one, because completeOAuth picked an existing credential to
update by guessing — matching on email, or falling back to "the only existing
credential for this provider" if there was exactly one.

• Replaces that guesswork with an explicit credentialId, threaded through
  the OAuth flow (initiateOAuth(credentialId) → OAuth state cache →
  completeOAuth) so the update path only ever fires when the user explicitly
  clicked Reauthorize on an existing credential.
• "Add Credential" now always creates a new row, regardless of how many
  credentials already exist for that provider or what email the new account
  uses.
• Applies to both the GitHub and GitLab providers.
• Adds unit tests covering the create-vs-update branching (new credential,
  second distinct credential, reauthorize-by-id, stale/cross-provider id
  fallback, invalid OAuth state).

Test plan

• npm test -w packages/insomnia -- src/sync/git/providers/__tests__/github.test.ts src/sync/git/providers/__tests__/gitlab.test.ts — 12/12 passing
• npm run lint on changed files — clean
• tsc --noEmit on changed files — no errors
• Manual: Settings > Git Credentials > Add Credential > GitHub, authorize Account A → Add Credential > GitHub again, authorize Account B → verify two separate credential rows exist
• Manual: open an existing credential's edit view and click Reauthorize → verify it updates that same row instead of creating a new one

[Copilot]

Pull request overview

This PR fixes an OAuth reauthorization edge case where authorizing a second account for the same Git provider could overwrite an existing credential. It does so by threading an explicit credentialId through the OAuth initiation → state cache → completion flow, so updates only happen when the user explicitly reauthorizes an existing credential; otherwise a new credential is always created.

Changes:

• Thread credentialId through the OAuth flow (UI → route action → main process → provider initiate/complete) to make update-vs-create explicit.
• Update GitHub/GitLab OAuth state caches to carry the reauthorization credentialId and use it to deterministically select the credential to update.
• Add unit tests for create-vs-update branching and invalid/stale state/id scenarios for both providers.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
packages/insomnia/src/ui/components/settings/credentials.tsx	Passes the edited credential’s id when clicking Reauthorize so the flow can update the intended row.
packages/insomnia/src/sync/git/providers/types.ts	Extends the provider interface to allow initiateOAuth(credentialId?).
packages/insomnia/src/sync/git/providers/gitlab.ts	Stores { verifier, credentialId? } in the state cache and uses credentialId to update only the explicitly reauthorized credential.
packages/insomnia/src/sync/git/providers/github.ts	Stores state -> credentialId? and updates only the explicitly reauthorized credential (otherwise always creates).
packages/insomnia/src/sync/git/providers/tests/gitlab.test.ts	Adds unit coverage for GitLab OAuth create-vs-update branching and state/id edge cases.
packages/insomnia/src/sync/git/providers/tests/github.test.ts	Adds unit coverage for GitHub OAuth create-vs-update branching and state/id edge cases.
packages/insomnia/src/routes/git-credentials.init-sign-in.tsx	Extends the route action payload to forward credentialId from the renderer to the main process.
packages/insomnia/src/main/git-service.ts	Updates the main-process entrypoint to accept credentialId and pass it into initiateOAuth.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[CurryYangxx]

"Add Credential" now always creates a new row

This UX seems a bit wired. At first, we only add a new row for a different account, and update the existing one if the email is the same. Not sure if this will make user confuse.