Promote bulk history replay + GitHub push into a first-class muse bridge capability

Promote bulk history replay + GitHub push into a first-class muse bridge capability

Background

While using muse bridge git-export to build a real disaster-recovery backup of the muse repo's full history to GitHub (see musehub issue #127), the actual Muse→Git translation primitive (muse bridge git-export) was exercised across ~1,480 real commits with zero bugs found in the bridge itself. Every issue encountered lived entirely in the bash orchestration wrapping it (muse/scripts/muse-git-backup.sh):

• A SIGPIPE footgun in echo "$commits" | head -n "$LIMIT" that only surfaced at real scale (pipe-buffer boundary), never in small test fixtures.
• A GitHub account/protocol mismatch (hardcoded gabriel/... instead of the actually-authenticated cgcardona account; SSH remote URL instead of the HTTPS protocol gh auth status actually configures).

muse bridge git-export operates on exactly one Muse ref per invocation — there is no built-in concept of "replay the full history" or "push the result to a hosting provider." That orchestration currently lives entirely in bash: walk muse rev-list --reverse, call git-export once per commit, handle gh repo create/push separately, implement --skip/--limit, verification (clone + diff), and incremental resume by reading .muse/git-bridge.toml directly.

Goal

Evaluate promoting "bulk historical replay to a git target" into a first-class, tested Python capability of muse bridge itself — e.g. a --full-history flag on git-export, or a new subcommand (muse bridge git-mirror?) — so that:

1. Any Muse user can replay a full commit history to a git working tree without needing bash, gh, or hand-rolled orchestration.
2. The replay loop, resume logic, and skip/limit semantics get real pytest coverage (matching this repo's TDD conventions) instead of living in an untested-by-CI bash script.
3. GitHub-specific push/repo-creation stays explicitly out of muse bridge's scope — that's a hosting-provider concern, not a Muse↔Git bridge concern. (Whether it belongs in muse hub-style tooling instead is a separate question, out of scope here.)

This is explicitly a design question, not a decided feature — the right shape (new subcommand vs. flag vs. leaving it as user-level tooling) needs real design work before any TDD phases are written. Do not start Phase 1 until that design is reviewed.

Out of Scope

• Any GitHub-specific logic (repo creation, gh invocation) — stays outside muse bridge's domain regardless of how this resolves.
• Changing muse bridge git-export's existing single-ref contract — this is additive, not a replacement of the current behavior.
• scripts/muse-git-backup.sh itself — it works, is tested at the bash level, and continues to serve the disaster-recovery backup task (musehub issue #127) regardless of this ticket's outcome.

Open Questions (resolve before Phase 1)

• Is a new subcommand or a flag on git-export the better shape? A flag changes git-export's contract from "one ref" to "one ref or a range" — worth weighing against a dedicated subcommand that's obviously bulk-only.
• Should incremental resume (reading .muse/git-bridge.toml's last_export.muse_commit_id) become bridge-native, or stay a caller responsibility?
• Does this belong in muse bridge at all, or is "mirror my full history to git" more naturally a muse top-level command (e.g. muse git-mirror) given it's really about the whole repo, not a bridge-domain concern per se?