gh stack link --remote <fork> queries the fork’s parent repository

## Summary

In a fork clone with separate upstream and fork remotes, `gh stack link --remote fork` queries the stack API for the upstream parent repository instead of the selected fork.

This prevents linking existing PRs when access to the parent is restricted, even though the authenticated user can access the fork and all PRs being linked have both their base and head repositories in the fork.

This appears related to #381, but that report covers `gh stack submit` selecting `origin` in a multi-remote clone. This reproduction covers `gh stack link`, has no `origin` remote, and shows the extension selecting a fork's parent despite an explicit `--remote`, `remote.pushDefault`, and `gh-resolved` repository.

## Environment

- `gh version 2.100.0 (2026-09-03)`
- `gh stack` / `github/gh-stack` v0.1.1
- Repository: `/`, a fork of `/`
- Two existing PRs whose base and head repositories are both the fork

## Repository configuration

```text
$ git remote -v
fork git@github.com:/.git (fetch)
fork git@github.com:/.git (push)
upstream git@github.com:/.git (fetch)
upstream no_push (push)

$ git config --get remote.pushDefault
fork

$ git config --get remote.fork.gh-resolved
/

$ gh repo set-default --view
/
```

The local `.git/gh-stack` state was initialized with the parent repository despite this configuration:

```json
{
"schemaVersion": 1,
"repository": "github.com:/"
}
```

## Steps to reproduce

1. Clone a GitHub fork with one remote for the fork and a separate fetch-only remote for its parent. There is no `origin` remote.
2. Set the fork as the push/default GitHub repository:

```sh
git config remote.pushDefault fork
git config remote.fork.gh-resolved /
```

3. In the fork, create two open PRs intended to form a stack. Both PRs have base and head repositories equal to `/`.
4. Run:

```sh
gh stack link --base main --remote fork --open
```

## Actual behavior

The extension calls the parent repository's stack endpoint and fails:

```text
Checking existing stacks...
failed to list stacks: HTTP 403
(https://api.github.com/repos///stacks?per_page=100&page=1)
```

The authentication failure is expected for that parent repository. The unexpected behavior is querying the parent at all.

## Expected behavior

`gh stack link --remote fork` should query and mutate stack metadata in `/`, matching:

- the explicitly selected remote;
- `remote.pushDefault`;
- standard `gh` repository resolution; and
- the base/head repository of every PR passed to `--open`.

If these signals disagree, the extension should fail before making an API request and report which repository needs to be selected.

## Controls

The correct fork endpoint is accessible with the same authentication:

```sh
gh api 'repos///stacks?per_page=100&page=1'
# HTTP 200
```

Running the same link command from a temporary Git repository whose only remote is `/` succeeds:

```text
Created stack with 2 PRs
```

This isolates the failure to repository resolution in the multi-remote fork clone rather than authentication, PR shape, or stack creation.

## Impact

- `gh stack link` cannot be used normally in this fork/multi-remote layout.
- Users may receive misleading authentication errors for a repository they did not select.
- Where the user has access to both repositories, the command may read or write stack metadata in the wrong repository.

## Workaround

Run `gh stack link` from a temporary repository configured with only the fork remote. This is error-prone and loses the normal relationship with the working clone.

## Related

- #381 reports the likely shared repository-resolution defect for `gh stack submit`.
- #461 reports stale fork/parent metadata affecting `gh stack submit` after a remote rename.

If maintainers consider `link` covered by #381, I am happy for this to be closed as a duplicate; the additional reproduction may still be useful for a regression test.

まず、マルチリモートのフォーク構成で `gh stack link --base main --remote fork --open ` を再現し、その後、リポジトリの解決と `.git/gh-stack` の状態を調査します。コマンドがフォークのエンドポイントを使用し、競合するリポジトリシグナルが API リクエストの前に明確な選択エラーで失敗すれば完了です。このシナリオの回帰テストを追加してください。

索引モデルが issue の本文から書いたものです。