`gh stack` resolves the API repository from the `origin` remote, ignoring `--remote`, `gh repo set-default`, and its own state file — silently operating on the wrong repository in multi-remote clones

## Summary

In a clone with multiple remotes, every `gh stack` PR/stack API operation is bound to the repository of the **`origin`** remote, regardless of:

- the `--remote` flag (which only changes the *push* target),
- `gh repo set-default` / `remote..gh-resolved` (the standard gh CLI repo resolution),
- the `repository` field in `.git/gh-stack` (editing it has no effect on subsequent runs).

If `origin` points at a different repository than the one your branches and PRs live in — the completely standard fork workflow where `origin` is upstream and you push to your fork — `gh stack submit` pushes to the right remote but then tries to **create PRs and stacks on the wrong repository**. In `--auto` / non-interactive mode this happens silently: there is no "Multiple remotes found" prompt (the interactive path in #219 at least shows one).

In my case the only reason no PRs were actually opened against the upstream project is that my branches don't exist there, so every `createPullRequest` failed. If upstream had happened to contain same-named branches, `gh stack submit --auto` would have opened a pile of PRs against a repository I never pointed it at. For agent/scripted use this is a dangerous default.

## Environment

- gh version 2.96.0
- gh-stack v0.1.0
- Clone with 7 remotes; `origin` = `github.com/argoproj/argo-workflows` (upstream), `joibel` = `github.com/Joibel/argo-workflows` (fork, where all stack branches and 8 open PRs live)
- `gh repo set-default Joibel/argo-workflows` is set (`remote.joibel.gh-resolved = base`)

## Steps to reproduce

1. Clone a repo with `origin` pointing at upstream and a second remote pointing at your fork.
2. Create branches with open PRs on the fork (head and base both on the fork).
3. `gh stack init --base ... ` — adopts the branches fine, but records `"repository": "github.com:/"` in `.git/gh-stack`.
4. `gh stack submit --remote --auto`

## Observed

- Push goes to the fork remote correctly ("Pushing to joibel... ✓ Pushed and synced 8 branches").
- All PR operations target the `origin` repository: existing fork PRs are not detected, and the extension attempts `createPullRequest` against upstream, failing with:

```
⚠ failed to create PR for : creating PR: GraphQL: Head sha can't be blank,
Base sha can't be blank, No commits between and ,
Head ref must be a branch, Base ref must be a branch (createPullRequest)
```

(Same error signature as #219, different root cause — here the refs genuinely don't exist because it's querying the wrong repository.)
- The interactive TUI confirms it: the header shows `Repo: argoproj/argo-workflows` even when invoked with `--remote joibel`.
- None of the following change the target repository: `--remote`, `gh repo set-default`, editing the `repository` field in `.git/gh-stack`.

## Workaround

`GH_REPO=/ gh stack submit --remote --auto` works perfectly — existing PRs are detected ("PR #NN for is up to date") and the stack is created.

## Expected

- Repo resolution should follow the standard gh CLI rules (`GH_REPO`, then `gh-resolved`/`gh repo set-default`, then remote heuristics), or at minimum follow the remote selected with `--remote`, since a stack's branches and PRs must by definition (#46) live in the repository the branches are pushed to.
- If resolution is ambiguous in non-interactive mode, fail with an explicit "multiple remotes, specify GH_REPO or --remote" error rather than silently picking `origin`.
- `gh stack init` should surface/validate which repository it bound the stack to.

## Related

- #219 — same GraphQL error signature via a different resolution failure; its interactive run at least got a "Multiple remotes found" prompt, which `--auto` skips.
- #45, #337 — same code area (deriving the API repo from remote URLs) tripping on SSH aliases / hostname remaps.
- #46 — cross-fork stacks; confirms head+base must be one repository, which makes binding to `origin` doubly wrong when pushes go elsewhere.

Start by tracing repository resolution from the `gh stack init` and `gh stack submit` entry points, including `--remote`, `GH_REPO`, `gh-resolved`, and the `repository` field in `.git/gh-stack`. Compare the selected repository with the push remote and verify that interactive and `--auto` flows either target the intended repository or fail explicitly when resolution is ambiguous.

Scritto dal modello di indicizzazione a partire dal testo della issue.