[Feature]: Support non-origin upstreams when showing associated PRs

[tyteen4a03]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

The app assumes the primary git remote is always named origin in several places that drive PR association:

• apps/server/src/sourceControl/SourceControlProviderRegistry.ts (selectProviderContext) picks the remote literally named origin first, before falling back to any other detected provider remote.
• apps/web/src/lib/baseRefChoices.ts prefers the origin remote when resolving base ref candidates.
• apps/web/src/components/GitActionsControl.tsx defaults the publish remote name to "origin" and its guidance copy ("Add an origin remote before pushing...") assumes that name specifically.

Repos cloned from a fork (where origin is the fork and upstream is the real remote), or set up with a custom remote name, can end up with associated-PR lookups silently targeting the wrong remote, or missing the PR entirely if origin doesn't point at the provider repo the PR actually lives on.

Proposed solution

• Stop hardcoding "origin" as the assumed remote when resolving which remote to query for associated PRs. Use the remote that the current branch actually tracks (its upstream) as the primary signal, falling back to provider-detection heuristics only when there's no tracking info.
• Update the fallback order in selectProviderContext so a branch's actual upstream remote wins over a same-named origin remote that isn't the tracked one.
• Update GitActionsControl.tsx copy/defaults so they don't imply origin is required, only that some remote must exist.

Bonus point: If a branch has multiple PRs to different origins, T3 Code should show all PRs.

Why this matters

My setup has multiple remotes, one of which I habitually don't call origin. While I can trivially rename my upstream, it may not be possible for others.

Smallest useful scope

N/A - suggestion already the minimum scope. Implementing the bonus points however would be great!

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.