gh stack init silently recreates an existing branch from trunk (instead of adopting it) when only a remote-tracking ref exists, and submit force-pushes over the real branch, destroying its history and closing its PR

## Environment
- gh-stack v0.1.0
- gh 2.97.0
- git 2.50.1
- macOS

## Summary
`gh stack init ` treats a branch as "new" (and creates it fresh from trunk) if no *local* branch of that exact name exists — even when a remote-tracking ref for it does exist, with real commits and an open PR behind it. `gh stack submit` then force-pushes that empty, trunk-tip branch over the real remote branch, silently deleting its commits and causing GitHub to auto-close its PR (empty diff → nothing to merge).

## Root cause (traced in source)
- `internal/git/gitops.go` `BranchExists` calls `client.HasLocalBranch(...)` — it never checks `refs/remotes//`.
- `cmd/init.go`'s `resolveArgBranches` treats "not found locally" as "doesn't exist," and runs `git.CreateBranch(name, parent)` (parent = trunk for the bottom-most branch) — i.e. `git branch `, discarding any relationship to the real branch/PR of the same name.
- The success message still prints "Adopted N branches" regardless of whether a branch was actually adopted or freshly (and destructively) created — no warning is shown.
- `cmd/submit.go:227` then unconditionally force-pushes every branch (`git.Push(..., force=true, ...)`, using `--force-with-lease` under the hood) — the lease only guards against a concurrent change by someone else, not against gh-stack pushing an unrelated commit on purpose.

## Repro
1. `feature-x` exists on `origin` with real commits and an open PR, based on `main`.
2. Without ever creating a local branch named `feature-x`, branch off it under a different name: `git checkout -b my-work origin/feature-x`.
3. `gh stack init feature-x my-work` → prints "Adopted 2 branches" but actually ran `git branch feature-x main` for `feature-x`.
4. `gh stack submit` → force-pushes the empty `feature-x` to `origin`, wiping its real commits. GitHub auto-closes `feature-x`'s PR since the diff is now empty.

## Impact
Silent, unwarned history loss on a shared branch with real, reviewed work behind it. In our case the original commits happened to still be reachable via another local branch built on top before the incident, so we could restore them — anyone without that would have lost the work (short of GitHub's own object retention).

## Suggested fix
Before classifying a branch as new in `init`, also check for a remote-tracking ref (or fetch first); if one exists, create the local branch from it (`git branch /` or equivalent) instead of from trunk. Separately, `submit`/`push` force-pushing should sanity-check that it isn't collapsing a branch's diff to zero relative to what's currently on the remote, or at minimum surface a loud warning before doing so.