`gh stack view` silently ignores positional arguments, including a valid different stack number

## Summary

`gh stack view` accepts no positional argument, but supplying one is silently discarded instead of rejected. The harmful case is passing a **valid stack number that isn't the current one** — you get a different stack's contents, with that stack's number in the header, and no indication your argument was ignored.

On a branch belonging to stack #6, asking for stack #3 (which exists):

```
$ gh stack view --short 3
Stack #6 <-- rendered #6, not the #3 that was requested
├ stack-b-two ○ #5
» stack-b-one ○ #4 (current)
└ main

$ gh stack view --short garbage999
Stack #6 <-- also silently succeeds
├ stack-b-two ○ #5
» stack-b-one ○ #4 (current)
└ main
```

Exit status is 0 in both cases.

## Why this matters

The output carries a stack number in its header, so it reads as authoritative. Anyone comparing two stacks — or scripting against `view` — can act on the wrong one without any signal. It is also a natural mistake to make, because `gh stack checkout` *does* take a stack number, so the two commands look like they share a selector.

## Reproduction

In a repo with two stacks:

```bash
git switch
gh stack view --short # shows stack B
gh stack view --short garbage999 # shows stack B
```

Public repo with two stacks set up for this: https://github.com/xn/gh-stack-repro

## Expected

Either error with `unknown argument "3"` (the usual `gh` behaviour for unexpected positionals), or accept a stack selector here the way `gh stack checkout` does. The latter would also give a non-interactive escape hatch for the ambiguity in #415.

## Environment

- `gh` 2.97.0
- `gh-stack` v0.1.0
- git 2.50.1
- macOS 26.4.1, darwin/arm64

從 `gh stack view` 命令的引數解析開始，重現 issue 中的兩個命令，包括它們的結束狀態和輸出。檢查 `gh stack checkout` 如何處理 stack 編號，然後為有效和無效的位置引數新增涵蓋測試。完成的標準是該命令不再靜默忽略這些引數：它應該明確拒絕這些引數，或一致地支援 stack 選取。

由索引模型根據 Issue 內容生成。