init writes branch.<name>.remote = '.', so submit reports a push that never happened

## Environment

- gh 2.96.0 (2026-07-02), gh-stack **v0.0.4**, git 2.46.1, macOS 26.6
- Run inside a **git worktree** (`GIT_DIR=.git/worktrees/`)
- `origin` is the canonical repo name, not a rename

## Summary

`gh stack init` wrote `branch..remote = .` into git config. `.` means *this local repository*, so the subsequent `gh stack submit` pushed nowhere, printed `Pushing to ....`, and still reported `✓ Pushed and synced 2 branches`. The branches did not exist on `origin`.

This is the same failure as #461 and the same family as #472, but a different trigger. There the cause was a renamed repo; here it is the remote config that `init` itself wrote.

## Repro

```
git worktree add ../wt -b feature/a
# ... commit on feature/a, then branch feature/b on top, commit
gh stack init --base develop feature/a feature/b
git config --get-regexp 'branch\.feature.*remote'
```

Observed:

```
branch.feature/a.remote .
branch.feature/b.remote .
```

Every other branch in the same repo that was not created by `gh stack init` has `remote origin`.

Then:

```
gh stack submit --auto
```

```
Checking stack state...
Pushing to ....
⚠ failed to create PR for feature/a: creating PR: GraphQL: Head sha can't be blank,
Base sha can't be blank, No commits between develop and feature/a,
Head ref must be a branch (createPullRequest)
✓ Pushed and synced 2 branches
```

`git ls-remote --heads origin 'feature/*'` returns nothing. The push never happened, but the last line says it did. The PR-creation error is a downstream symptom: GitHub cannot see a branch that was never pushed.

## Workaround

```
git push origin feature/a feature/b
git branch --set-upstream-to=origin/feature/a feature/a
git branch --set-upstream-to=origin/feature/b feature/b
```

After that, `gh stack submit` prints `Pushing to origin...` and works correctly. The stack view and the GitHub-side stack were unaffected throughout.

## Why it matters

The empty remote name renders as `Pushing to ....`, which reads as ordinary progress ellipsis rather than an empty value, so there is nothing on screen to notice. Combined with the unconditional `✓ Pushed and synced` line, the command looks like it succeeded. I only caught it because PR creation happened to fail in the same run; on a stack where the PRs already exist, `submit` would report success and silently push nothing.

Given #461 and #472 report the same shape from different causes, the general fix may be for `submit` to verify the push landed rather than trusting it, and to refuse an empty or `.` remote outright.

## Note

I have not isolated whether the worktree is required to reproduce. It may be related to #459, which reports that gh-stack ties local state to `$GIT_DIR` and that a worktree changes it.

Reproduce the worktree scenario with `gh stack init --base develop feature/a feature/b`, inspect the resulting `branch.*.remote` values with `git config`, then run `gh stack submit --auto` and compare with `git ls-remote --heads origin`. Done means init does not create an unusable `.` remote and submit does not report success unless the branches actually reach the configured remote.

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