feat(wren): add wren cloud to bind a local project to a Wren Cloud git remote - #2706

…mpotency

macOS git ships an osxkeychain helper in system config, which is consulted
before global config. Without resetting it, login's helper never actually
answers `get` first, so a stale keychain-cached token can be served instead
of a fresh one — and because this design never caches, `store` still fires
on every operation, persisting the ephemeral token into the keychain
anyway. Write an empty `helper =` first in the URL-scoped section to reset
the inherited chain for that host only; other hosts keep their own helper.
--replace-all followed by --add keeps repeated `login` runs idempotent
(verified by actually re-running it, not just reading the sequence).

Also fix pull()'s local-commit step: it decided whether a commit was still
needed by checking whether `.git` existed, which conflates "some earlier
attempt got as far as `init`" with "a commit actually landed". A retry
after a failed `commit` (e.g. missing git identity) would silently skip
straight to the remote merge against an unborn HEAD, turning the
unrelated-history merge into a trivial fast-forward. Ask git directly via
`rev-parse --verify -q HEAD` instead.

(cherry picked from commit e24bf8a43743b1818321a8084da8920d10851094)
(cherry picked from commit c8c23c1b31988cca143b6f736316f389d1e465b9)
(cherry picked from commit ed9c08083526a0a53080bde5668916eb08601031)

…splays

`--host`'s help text calls it "the host used at login" and the
disambiguation candidates print `api_host`, but the filter matched
`git_host` instead. A user who passes the exact value they gave `login`
got a false "no stored login found", even though a matching login existed
under a different `--git-host`. Filter on `api_host`, the same field the
docs and the candidate list already use, so the two can't disagree.

Two logins that share an `api_host` but differ only by `--git-host` still
correctly fall through to the disambiguation error rather than being
silently missed or arbitrarily resolved.

(cherry picked from commit eb5516c518842ac46b2d4357cba6d918e2868e88)
(cherry picked from commit cf2b02e762f890cec37a3992e2eb2d834410373d)
(cherry picked from commit 1fc4798c68dd29361d067b27c630a0ea9c6ac8a3)

`pull` was never an update path — it acquires a project's files once via
a plain clone or a one-time unrelated-history merge, and every further
sync is ordinary `git pull`/`git push`. Keeping the name `pull` invited
users to expect repeated invocations to behave like git's own pull.

Rename the command and its underlying function to `link`, and give
re-runs an explicit "already linked" outcome: when the target directory
is already caught up with the remote, `link` now reports that and points
at `git pull` for updates instead of quietly re-merging. Recovery from a
partially-completed previous attempt (unborn HEAD) still works exactly as
before — only the fully-caught-up case short-circuits.

No behavior change to `login`, the git-credential helper, or the
acquisition logic itself (clone path, git-init+merge path, nested-repo
refusal, upstream wiring).

(cherry picked from commit 11e190c02ffb099c7f323a345dedbcc966403647)
(cherry picked from commit 9f3fcdcbf2eb1e769d788f9c4a207b1bcc559f5f)
(cherry picked from commit 0abd2011f300ede891c35ced63f77c2e55d08d4a)

… step

`create` is the other half of `link`: both bind a directory to a Wren
Cloud project, differing only in whether the project has to be made
first. It always requests the AGENTIC opt-in (a project created any
other way has no git repository to bind to), takes the org key only
transiently to create the project and mint its own project key, and
then reuses `login`/`link`/`check_not_nested` unmodified to reach
exactly the state `link` leaves a directory in — a plain `git push`
works afterward with no further `wren` command.

If the server did not actually grant the AGENTIC opt-in, that surfaces
as a specific, actionable error instead of a bare 404, with the
project's freshly minted key included so it is recoverable via `wren
cloud login` rather than orphaned.

(cherry picked from commit 75ce6da8a7b9a4335866fd21db14b648780dc067)
(cherry picked from commit a05cd2632c3e9a9ca67d087440269497f8ffafdb)
(cherry picked from commit b256407c512b947392d6687568620bfaf5ba3309)

… prose

mint_git_token's generic-error branch now parses the response body and
attaches the HTTP status and machine-readable `code` to a new
CloudApiError (a CloudError subclass), degrading to `code=None` on any
body that isn't the expected shape rather than raising. `create` matches
on `code == "PROJECT_NOT_AGENTIC"` instead of substring-matching the
error message, so an unrecognized 404 (different code, no code, or an
unparseable body) reliably falls through to the generic bind-failure
message instead of risking a silent misdiagnosis.

Existing callers (the credential helper's `get` and `login`) are
unaffected: the raised message text is unchanged, and CloudApiError is
still a CloudError.

(cherry picked from commit dee334c5eaf058aec2694b72bd5464dac9ca505d)
(cherry picked from commit 264060121e8ce35ea44c2726aa06ce27b00aa506)
(cherry picked from commit 9fbc1f3df8417b3e93da53468d682014f11f55eb)

Every key the CLI mints landed in the user's key list under one constant
name, and the server stamps all API-minted keys with the same origin, so
the list gave no way to tell one from another.

The host name would also distinguish same-day mints from different
machines, but it would put the machine's name into the account's key
list; that trade was declined, and a test guards against it creeping
back in.

(cherry picked from commit f71e6953ea15b398727e3b66f234f79ae1b60f5c)
(cherry picked from commit 47dd75864ceb5262b554537abfdd106d81ff1fd4)
(cherry picked from commit 7d939ec5dbd069fb30bad14188d9be255481565e)

`wren cloud login` writes `!wren cloud git-credential` into global git
config, and the leading `!` makes git resolve `wren` from PATH at
git-invocation time — not at login time, and not pinned to the interpreter
that ran login. A `wren` on PATH without the `cloud` commands therefore
breaks every clone / fetch / push against that host, with an error that
comes from git, talks about credentials, and names neither wren nor a
version. login reported success regardless, because at login time the CLI
is the capable one; the breakage appeared later, in a different tool.

login and create now probe the PATH-resolved `wren` before writing
anything and refuse with a message naming that executable and how to fix
it. create runs the check before creating the project server-side, so a
refusal cannot leave an orphaned project behind. The helper string written
into git config and the command the probe asks about are now derived from
one definition, so a change to one cannot leave the other verifying a
command git never runs.

The check cannot cover PATH changing after login — once a different `wren`
is what git runs, nothing on this side is in the path of the failure — so
the helper's own failures now identify themselves: the tool, its version
and the executable that actually served the request, printed immediately
above git's own credential error.

Also stop the unit tests from writing into the real global git config. The
create tests reach `git config --global` for real, and every run left a
dead `credential.<tmp path>` section behind in the developer's or CI
runner's own config file.

(cherry picked from commit 47c9cc98c2be3abe9be1ab62a39e2cff59da2fa9)
(cherry picked from commit 3360f110d531602d9fd08c6f4842d268fc8a625a)
(cherry picked from commit 44545a5f1aeffa646c3b0ccc2b3d0f07f52958ca)

…works

`link` set upstream tracking only on the branch that performs the merge.
The already-linked short-circuit returned before it, which is harmless for
a second run after a successful bind or for a plain clone — both already
track their remote.

It is not harmless in the state the conflict message itself creates. A
conflicted bind raises before upstream is set; the user resolves and
commits, as that message instructs; `origin/<branch>` is then an ancestor
of HEAD, so `link` reports "already linked, run `git pull`" and exits 0 —
with no tracking branch, so `git pull` and `git push` both refuse. The
command reported success and recommended a command that could not run.

Upstream is now set on that path too, and only when the branch has none,
so a deliberately re-pointed branch keeps its own. No merge is added, so
already-linked still means already-linked rather than a fresh bind.

Verified against a real server and git-server: in the directory left by an
actual conflicted bind, `git pull` went from "no tracking information" to
"Already up to date." and a plain `git push` landed a commit.

(cherry picked from commit 6a62505cc57ccfa3715426632dfa078ce07caa1d)
(cherry picked from commit bd932aea6e191d7f113202592472bf09c510a160)
(cherry picked from commit 09680c61eb050dd3888652a7deb8272ae1f4fe3d)

The directory-to-project binding is the git remote and nothing else, but
nothing guarded that remote's lifecycle. `link` only ever *added* `origin`
and never checked an existing one, so a directory bound to project A could
be handed project B and silently stay on A while the caller reported
success for B. Through `create` that also left B orphaned server-side:
created, keyed, and referenced by nothing. Reproduced against a live
server, where it created a real project.

`create` now refuses a directory that is already bound, or whose history
came from a project, *before* touching the server — beside the existing
nested-repo and helper checks, so the refusal leaves nothing behind.
`link` verifies an existing `origin` matches the repo it was asked to bind,
and refuses to merge a history that shares no ancestor with the target
project rather than combining two projects' content for the next push to
publish. That refusal rolls back the `origin` it added.

The guards block operations users legitimately need, so `unlink` and
`logout` land with them. `unlink` removes the remote and keeps the stored
key by default, since another directory may still be bound to the same
project; `--forget-key` drops it too. Both remove the host's credential
helper only once no stored login uses that host, because that entry is
shared by every project on it.

Detecting the foreign history needed two conditions, not one: "origin is
not an ancestor of HEAD" is also false when a clone is merely behind the
same project's remote. Keying the refusal off that alone rejected the
ordinary unlink/re-bind recovery — found by driving it against a live
server, and now pinned by a regression test.

(cherry picked from commit a7d3992ccfc8a49a1bb887525d569b83e7ecedd4)
(cherry picked from commit 229bf05e3ca18d331a45343cb2f8157ba64e9cf0)
(cherry picked from commit 67a9299f6dca87ba9836bf43175e6a26ab3a1892)

`--force` already meant two different things in this CLI: "overwrite files"
(`wren context init --force`) and "skip the confirmation prompt" (`profile
rm`). The second is the odd one out — and actively misleading for the cloud
commands, where the product's own guidance is never to `git push --force`
and where the binding guards deliberately have no bypass at all. A user
reading `wren cloud unlink --force` could reasonably expect it to override
a refusal. It does not, and never will.

So the confirmation-skipping flag is now `--yes`/`-y` everywhere, leaving
`--force` to mean overwriting, consistently.

`wren profile rm` is already released, so `--force`/`-f` keep working there
as deprecated aliases rather than breaking scripts; the new cloud commands
have never shipped and take `--yes`/`-y` only.

Adds tests/unit/test_profile_cli_flags.py for this, because
tests/test_profile_cli.py — which covers `rm` far better — is referenced by
no CI job, so a regression in a shipped flag would not have been caught.

(cherry picked from commit d0ac90a9bd0d2f10f1a2d826e5002beac6be1bc2)
(cherry picked from commit 51b35b6fd17879dddd74980a2b48827591eadf0c)
(cherry picked from commit 0e473c1fcec3df40ed9e93ce86a81dc30ad25515)

… means more

Finishes the confirmation-flag rename. `wren memory reset` only ever asked
"are you sure", so it takes `--yes`/`-y` now, with `--force`/`-f` kept as
deprecated aliases since the command is released.

`wren memory forget` deliberately keeps `--force` as its documented name.
Its flag is not a confirmation skip: it selects non-interactive mode — the
checkbox UI is skipped, and `--source` only deletes in bulk when the flag is
present. Calling that `--yes` would describe it wrongly. `--yes`/`-y` are
accepted as aliases anyway, so a user who learned the vocabulary elsewhere
is not turned away.

So across the CLI: `--yes` skips a prompt, `--force` does something
stronger — overwrite files, or change mode.

The new flag tests cover both commands by option parsing only, so they need
no `memory` extra and run in the default unit job. tests/unit/test_memory.py
runs in its own CI job behind that extra, where a flag regression would not
have been caught by the default one.

(cherry picked from commit 677ec4cbdf6a36c3d0eb62e18c884df48c041edf)
(cherry picked from commit d29cff61d7c8805c1488c14322daf60274f8088a)
(cherry picked from commit 06b605bc4a172c7788ac828fc1f2ca4fdf5754be)

`create_project`'s 401 said the key was probably a project key rather than an
org key. The CLI already refuses a non-`osk-` key before this call, so that was
never a reachable cause — and sending someone to look for a key they already
have is worse than saying nothing. It now names the org and host and says what
is actually likely: revoked, or belonging elsewhere.

(cherry picked from commit 4ed301e5e444fb9c6be20765671458d675e61109)
(cherry picked from commit cc402e6fa2f37c2cbc813cf3841ea262ca008204)

`login --project <id>` borrowed a verb whose every precedent is host-scoped
— `docker login <registry>`, `gh auth login --hostname` — for an operation
that is necessarily project-scoped: the credential itself may be a project
key, and the endpoint that validates it and yields the repo path is
per-project. Logging in to a single resource is not what the verb means.

`auth add` / `auth remove` say what the commands do: they add and remove a
stored credential. Nothing here is a session, and after the recent removal
of the stored-key lookup nothing reads ambient state at all — so the name no
longer suggests one. That suggestion is what made "we are logged in, so
create should not ask" feel natural, and it cost a round of work.

Grouping them under `auth` also puts them next to `git-credential`, the
other credential-machinery command.

Free to do now: `wren cloud` has never been merged to main and this branch
has never been pushed, so there is no compatibility surface. It would not be
free later.

Internals keep "login" as a *noun* for a stored entry — `store_login`,
`list_logins`, `remove_login` — which reads correctly and is what the file
already called it. Only the commands and the prose that referred to them as
commands changed.

(cherry picked from commit 92d5595667a6e6225980de09cd2eab72a129bc22)
(cherry picked from commit 1a81bb02eaabc5b294575930f2a3608bcca53fd4)
(cherry picked from commit 52347b1b9de6c00b4d8dab7b82379c6e54723328)

The foreign-history refusal was applied to `create` as well as `link`, which
blocked a legitimate flow: unlink a directory, then create, to duplicate a
project's content into a new one.

The two cases are not the same. `link` to an *existing* project must refuse,
because that remote may hold other people's content and merging an unrelated
history into it publishes a mixture. A project created moments ago holds
nothing but its own seed commit, so there is no content to protect — and the
merge is precisely how the duplicate gets its starting point. `link` now
takes `remote_is_fresh`, which `create` passes, exempting only that case.

Removing `create`'s pre-flight alone would have recreated the orphan bug:
the refusal inside `link` fires after the project and key exist. Hence the
parameter rather than just deleting the check.

Driving the duplicate flow live then exposed a second, unrelated orphan path
this had missed: with no git identity configured, `create` built the project
and failed inside the merge, leaving it referenced by nothing. Binding a
directory that has files records commits, so the identity belongs in the
pre-flight. An empty target is exempt — that path is a clone, which records
no commit.

Also corrects the test seeder: it distinguished two projects' seed commits by
varying the hook file's *contents*, which manufactured a merge conflict real
projects never produce. The server seeds a hook file with no project-specific
content, so two projects' hook files are identical; only the commit message
now varies, which is enough for distinct SHAs.

(cherry picked from commit d666a87ff630e2ce9aea6b0dd124534827851721)
(cherry picked from commit e1cfbc7086440c6c7ef648909a0ddaf8995a4225)
(cherry picked from commit 38ffccad068e83c44d4f0590da34eeee7c9cbb41)

Everyone targeting the managed deployment had to type the same --host on
every `auth add` and `create`. It now defaults to https://cloud.getwren.ai.

Only where --host names the *target* of a command. On `link` and
`auth remove` it selects among stored credentials instead, and defaulting a
filter would hide a credential the user does have, so those keep no default.

A bare hostname now gets https:// prepended, because --host reads as a
hostname and that is what people type — without a scheme it reached requests
as a relative URL and came back as "Invalid URL ... No scheme supplied",
which looks like a fault in the tool rather than a fixable typo. An explicit
scheme is never overridden, so a local stack on plain http still works.

Since omitting --host now targets production instead of erroring, both
commands name the host in the key prompt. That is the one moment before
anything happens where a wrong host is still cheap to notice.

(cherry picked from commit 50467d95ca8447ce416239e40d9734264cb925b2)
(cherry picked from commit d510562bc03116b18e228a19692fd226f3f9061f)
(cherry picked from commit a0331984f4aee45f84a7c69ea6e4e20ee8a4e9bb)

A bind failure after creation escaped as a bare git error. Observed live: a
transient fetch failure against a just-created repo produced only

  Error: git fetch origin failed:
  fatal: protocol error: bad line length character: PACK

with no hint that a project now existed. It happened twice, leaving two
unexplained projects in the org that the user had no way to connect to what
they had just run.

The docstring already promised this recovery; the code never implemented it,
because the `link` call sat outside the try that handles the rest. It now
names the project, keeps the underlying git error visible, and says that only
the bind is missing — the key is already stored by then, so `wren cloud link`
finishes the job, or the project can be deleted if unwanted.

Deliberately not a retry. The trigger looks like a race between project
creation and the immediate first fetch, and a malformed protocol response is
never a legitimate "not ready" signal — papering over it in the client would
hide a server-side defect. Filed separately; a plain `git fetch` of the same
repo succeeds minutes later, so the failure is transient rather than a
property of fresh repos.

(cherry picked from commit d5c90f24f1a27166bea2681f21b0c77548719d30)
(cherry picked from commit 5bd9a4b7912ac6dd913f69e47ba34b3ea030e138)
(cherry picked from commit 85ba67d41072fab719083c76b54c03a9b3571eb8)

`wren cloud link` in the current directory reported

    Linked project 1234 into ..

The directory argument defaults to `Path(".")` and every message that names
it ends in a full stop, so the two run together and read as the *parent*
directory. Seven messages across link, create, unlink and unlink's
confirmation prompt shared the defect. They now resolve the path for
display; the commands still use it exactly as given.

Found while running the CLI against staging, not by the suite — no test
asserted on the defaulted-directory form, only on `str(tmp_path)`.

(cherry picked from commit 3b3deecf623eea3a6e32b77b781afcf1bc44a896)
(cherry picked from commit 82ebfef7c0e44494f3056498594865f6cb55bd06)
(cherry picked from commit 3d40ae56bc40c582703b0679995ae3b21ba4dbc7)

`create` produced a project the web UI reported as unfinished. It set up the
connection and the git remote, but a project with no models is
`DATASOURCE_SAVED`, not `ONBOARDING_FINISHED`, and nothing in this CLI could
take it further — the mutation that picks tables is GraphQL behind a session,
and the REST surface exposes models read-only.

`create` exists to turn a Wren project you already have into a Wren Cloud
project, so the models it should end up with are the ones already defined in
the directory. It now builds them, and refuses when there is nothing to
convert: no `wren_project.yml`, or YAML that does not compile. Both checks run
before the project is created, so a refusal still leaves nothing behind.

The models travel by git, not by the API. Uploading the built manifest as well
looked obvious and is wrong: the server materializes an uploaded MDL back into
`models/*/metadata.yml` in its own normalized rendering, which then collides
with the local YAML on bind — every file conflicted, add/add. So the manifest
is built to validate and thrown away, and `create` pushes instead. The push is
what fires `.hooks/deploy-modeling.yaml`, and that is what creates the models.

`--mdl-file` goes with it. The directory already is the manifest's source, at
a known path; a second way to supply one only reintroduces the two-authors
problem.

`--type` is upper-cased before it is sent, and its help now names values the
server accepts. It said `BIGQUERY`, which is not in the enum, and
`POST /api/v1/projects` does not validate the type: an unrecognized value
strips the connection info to `{}` and returns 207 with a project that has no
data source. Following the CLI's own help produced that. Reported separately;
the case fix is the part a client can own without mirroring the enum.

Verified end to end against a running deployment: `create` in a project
directory yields a project with its models deployed and the data source
connected — `type` set, no sample dataset, models > 0, which is the exact
condition the web UI reads as set up.

(cherry picked from commit aaf2f1b0860af70e4ff0b2a43c3df58299a636e3)
(cherry picked from commit 69a9998945022a44340106d82de59bd18f451361)
(cherry picked from commit 3503fd3e770293a43d9bb837007ac2fadc09c38a)

`create` accepted no `--type` and no connection info, and produced a project
with no data source. Wren Cloud reports that as still needing setup, and this
CLI cannot finish it: the only ways to attach a connection afterwards are a
REST call or the web UI. So the command was able to hand back a project that
nothing it owns could make usable.

Both are now required, and named individually when missing so the message says
which one to add. The refusal joins the others that run before the project is
created, so it costs nothing: verified live that the server-side project count
is unchanged across all three ways of getting it wrong.

The previous rule — `--type` required *when* connection info was given — is
subsumed. Its test is replaced by a parametrized one covering all three cases,
which also asserts `cloud.create` is never reached.

(cherry picked from commit b5835c552f933df484ec0d10017167e2519f2577)
(cherry picked from commit 946b6f5b0995b3cecd8ca1b336ee75cef06209de)
(cherry picked from commit 02cafb88c98048608c1f2648e1f8b4e59da28484)

Review found that nothing ever renamed the local branch. Wren Cloud seeds
`main`; a client whose git still defaults to `master` — upstream git's builtin
— ended up with the branch and its upstream disagreeing, and every symptom of
that read as success:

    local branch after link:     master
    upstream after link:         origin/main
    push origin HEAD -> rc=0
    remote branches after push:  [main, master]   <- a second branch
    remote main tip: b1606c5   local HEAD: 97983eb
    plain git push -> rc=128: "The upstream branch of your current branch
                               does not match the name of your current branch"

So `create`'s push reported success while pushing to a branch the deploy hook
does not watch, producing exactly the "project exists, is bound, and has
nothing in it" state that push was added to prevent — and the plain `git push`
this design promises, and the docstring claims, failed outright.

`_default_branch` already discovered the remote's name correctly and
`_set_upstream` already used it; only the branch itself was left behind.
`_align_branch_name` now renames it (or points unborn HEAD at it), before the
ancestor comparisons, which all speak in terms of `origin/<branch>`. A branch
that already has an upstream is left alone — the same rule the already-linked
path follows for a deliberate upstream.

Neither the suite nor live testing could see this: this machine's Apple Git
has a patched builtin default of `main`, and the fixtures hide global config,
so the stand-in remotes and the targets always agreed. The stand-in remotes
now pass `git init -b main` explicitly rather than inheriting whichever
builtin the runner has, and the new test forces the mismatch with
`git init -b master`. It asserts on the push landing on one branch, not just
on the branch name — the name alone would miss the second-branch symptom.

Also from the same review:

- `--git-host` was passed through raw while `--host` was normalized. A
  scheme-less value writes a git-config section git never matches, while the
  helper looks under the scheme-ful form, so both halves miss and `auth add`
  still prints that git is configured. Normalized at both call sites.
- `run_git` with a nonexistent cwd raised FileNotFoundError, which the CLI
  does not catch, so `link /no/such/dir` printed a traceback where every other
  refusal prints a message.
- `test_find_git_root_returns_none_when_absent` asserted `... is None or True`,
  which cannot fail. Replaced with the part that is actually knowable.

Verified live through the real CLI on a `master`-branch directory: branch and
upstream both end on `main`, plain `git push` works, and the deploy hook fires
(the models appear, and the project reports as set up).

(cherry picked from commit 3e7bfcafcf6aea29c19c3c4b2d4de68197d731e6)
(cherry picked from commit e914486fa82cffbb1c9130240eb75dfe94344b0b)
(cherry picked from commit baa6a7c6188f5b462412a410469db8cc140cb46d)

Review flagged the recovery hint: when `create` could not validate the key it
had just minted, it printed the key into the error so it would not be lost.
stderr routinely reaches CI logs and bug reports pasted verbatim, which is not
somewhere a live credential belongs.

The key is now stored before the validating call, so the message never has to
carry it — it says the key is already stored and names the one command that
finishes the job.

Storing first needed one adjustment to the reviewer's sketch: `store_login`
wants the repo path, and only `mint_git_token` returns it — the very call that
can fail. Rather than hardcode the server's repo naming, the key is stored with
an empty repo (`store_key_pending_repo`) and `resolve_repo` fills it in on
first use, via the same call the credential helper already makes on every git
operation. The helper itself never reads `repo` — it derives the repo from the
path git hands it — so an entry stored this way authenticates the moment it
exists; only `link` needs the field, and it now completes the record.

Three tests asserted the key *was* in the message. They now assert it is not —
and, because absence alone would also pass if the key had simply been dropped,
that it is retrievable from the store.

(cherry picked from commit 9d9ab3db5ac92dd5ae8ac454a724ca0065a82499)
(cherry picked from commit 56e5f344e5ba560a4324fdd034b98548456ee020)
(cherry picked from commit 3ea4e575215be3aece436f4eea967537f49511a7)

Round-2 review caught a gap the previous commit introduced. Storing the key
instead of printing it removed the credential from stderr, but `login` writes
the credential helper only *after* the git-token call succeeds — and that is
the call that fails on this path. So the key was stored and the hint said
"finish with `wren cloud link`", while link would fetch over HTTPS with no
helper for the host and git would prompt for a username. Reproduced: key
stored, no `credential.<host>.helper` section.

It was also worse than what it replaced: the old fallback was `auth add`, and
with the key no longer displayed — and no command that prints a stored one —
the user could not answer its prompt.

Fixed by configuring the helper alongside storing the key. Serviceability is
already checked in create's pre-flight and the write is idempotent. The test
asserts through `git config --get-urlmatch`, i.e. that *git* resolves a helper
for the host the hinted command will use, rather than that our file has a line
in it.

Three more from the same round:

- The rename refusal did not roll back an `origin` this call added, unlike the
  foreign-history refusal 60 lines below it. A refusal left the directory
  pointing at a project it was never bound to, so the next attempt refused
  "already bound" for a bind that never happened.
- `_align_branch_name`'s unborn-HEAD branch was unreachable: `link` commits any
  unborn HEAD before calling it. Removed rather than kept as untested defensive
  code. Detached HEAD now gets a message that says so, instead of "is on branch
  `HEAD`" plus git's rename error.
- `link --host` and `auth remove --host` compared the raw flag against the
  normalized stored `api_host`, so `--host cloud.getwren.ai` reported "no
  stored login" for a login that exists — the reading-side mirror of the
  `--git-host` defect fixed in the previous commit. Pre-existing, adjacent, and
  the same one-line shape.

(cherry picked from commit b2ca2c6702587d607c539cca61e7e12a93917a53)
(cherry picked from commit 8eb00583714fa97b011a017d309aabc1d8eb83f5)
(cherry picked from commit 352b08688422ddeb1c08d209eb33697327ebc6c2)

Last item from round 3. Moving the credential-helper write out of `login` took
it out of the except-block that names the project, so a failure there died with
a bare "git config --global ... failed:" — no project id, no mention that the
key is stored — on a path where the project and its key already exist.

The trigger is real, not hypothetical: `git config --global` fails with "could
not lock config file" when the global config's directory is not writable, and a
read-only home still *reads*, so the git-identity pre-flight passes and this is
the first write to fail. (A malformed global config fails earlier, at that
pre-flight, so it does not reach here.) Confirmed the reviewer's other candidate
does not reproduce: a read-only config *file* in a writable directory succeeds,
because git writes via a temp file and renames over it.

(cherry picked from commit 9b9c9a200e2fc898530cb3fae860e88488a7055d)
(cherry picked from commit 592494bcbb8acec2d7aa085ac077f4909245d627)
(cherry picked from commit 9144402e8fd85dab21f553e0336f70bcc4750a3f)

The commands shipped with no reference-doc entry — the docstrings were the only
documentation, which is not where anyone looks for a flag.

Leads with the two things that are not guessable from the flags: the binding is
the git remote (so plain git is the interface afterwards, and nothing local
records the directory-to-project mapping), and the credential split between a
durable on-disk project key and a per-operation token that never touches disk.

Every documented flag was checked against its subcommand's own `--help` rather
than written from memory, and the factual claims — the default host, the
credential path, its mode — against the source.

(cherry picked from commit f1b1d2c38cec1219c8e978e75ab0cdffbfda6da1)
(cherry picked from commit 33a89fabfb37bee636acc12e09175eb63e5afeb1)