No command for publishing a branch instance to the project remote

Summary

There is no command for "get this branch instance onto the project's real remote."
An agent working in a spawned workspace that wants to push and open a pull request
discovers that the workspace's origin is the local store path, not GitHub, and
has to hand-roll two hops: fetch workspace → store, then push store → origin.

This has now happened to several independent agents in separate sessions. Each one
rediscovers it, works around it, and writes a note about it. That repetition is the
signal — this is the "the agent will expect what is the norm" mismatch AGENTS.md says
to design away rather than document around.

Why it happens

spawn materializes a workspace with a plain local-path clone from the store
(GitSource::clone_to, crates/newgit-core/src/source.rs:136), so Git's default
naming makes the workspace's origin the store. Nothing afterwards touches remotes.

The thing that makes this easy to fix is that the store is not a separate artifact:
newgit init runs in place on the developer's existing repo
(crates/newgit/src/main.rs:497), so the store already has origin → GitHub
configured and untouched by newgit. The plumbing for the other hop exists too —
SourceRepo::fetch_ref (source.rs:150) already pulls a workspace's commits into the
store on checkpoint.

So both halves already exist. What's missing is a command that owns the sequence.

Proposal

newgit publish <instance>          # store fetches from workspace, pushes to origin
newgit publish <instance> --pr     # ...then `gh pr create --head <branch>`

Implemented so that it never touches the workspace's remotes at all: the store
fetches from the workspace clone (existing mechanism, unchanged), then the store
pushes its own already-configured origin.

Why not just make origin in the workspace point at GitHub

This was the first instinct, and it is superficially very much in the spirit of
"we will be lying to agents" — rename the store remote to newgit-store, call GitHub
origin, and git push / gh pr create work unmodified with no new vocabulary. It is
also about ten lines, and it would not disturb checkpoint mechanics, since fetch_ref
addresses the workspace by path and never reads its remote names.

It should still be rejected, because it hands the workspace push rights to a permanent,
shared, externally-visible remote — precisely the boundary fetch_ref's "fetch, never
push: the store pulls commits in when a checkpoint blesses them, and workspaces stay
passive" exists to draw. The concrete failure: an agent pushes, keeps working, and the
workspace is newgit removed before the next checkpoint. Commits are now on shared
history, absent from the store, with no record and no undo path back. undo has no
mechanism to unpush and no idea a push happened.

Routing every push through the store keeps two invariants separate and composable:
checkpoint blesses state; publish exposes blessed state. A workspace that can
publish directly collapses those into one operation with two different actors racing on
the same branch name.

Open question, with a proposed answer

Should publish auto-checkpoint a workspace with unblessed work, or refuse?

Proposed: refuse, and say so. Auto-checkpointing as a side effect of a command named
publish is the kind of surprising double-duty "boring beats clever" warns against, and
an explicit checkpoint step lets the output name the exact checkpoint id that was
published — worth more than the one saved command.

Size

Small. A Manager::publish in manager.rs reusing the existing fetch path plus a
git push from the store root, a CLI subcommand shaped like export's, and an optional
--pr flag that shells to gh when it is on PATH. No materializer changes, no changes
to clone_to or fetch_ref, no new remotes.

Whatever ships, spawn should also say one line about where origin points, so an agent
that reaches for plain git push first gets pointed at publish rather than silently
pushing into the store.

Notes

• newgit export is not this. It builds a new historyless repo with no remotes
  (export.rs, source.rs:401), deliberately discarding history and applying
  tracker-audience filtering — it cannot double as "push my branch's real history."
• The v1 spec never considered the project's real remote: its remote discussion
  (newgit-v1-mvp.md:1476-1486) is entirely about a future newgit-native remote for
  tracker sync (storage = "remote"), a different axis. This was not deliberately
  deferred; it was out of scope.
• Command shims are deferred to v2, so intercepting git push in a workspace is the
  natural v2 answer, not this one. A future shim could be implemented as publish.
• Adjacent to #82: nothing today models "this branch's tip is safe on some external
  durable copy." #82 wants that for remove --branch=if-merged; this wants it for
  "was this ever published." If publish ships first, remove could later ask the
  same question.

Start with Manager in manager.rs and the CLI entry point in crates/newgit/src/main.rs, comparing the proposed command with export and the existing SourceRepo::fetch_ref path in source.rs. Done means publish fetches the workspace into the store, pushes the store's origin without touching workspace remotes, refuses uncheckpointed work, and optionally invokes gh for --pr.