I’d be careful about treating the v0 workspace checkout as the source of truth once the remote identity has changed and promisor objects are missing.
With a partial clone, Git can leave some blobs out locally and fetch them later from the configured promisor remote. If the workspace was cloned from one repo and then origin was changed to another repo, Git may try to fetch missing objects from a remote that does not actually have those objects. That would explain why pushing/archive operations start failing even after correcting the remote URL.
For recovery, I’d use a fresh local clone of the intended GitHub repo instead of trying to repair the v0 workspace in place:
git clone --no-filter <correct-repo-url> stageos-unified-recovery
cd stageos-unified-recovery
git fsck --full
Then copy/export the latest app files from v0 into that clean clone, commit them on a new branch, and push that branch to GitHub. That gives you a clean repository identity and avoids pushing from a potentially inconsistent partial clone.
If you still have terminal access inside the v0 workspace, these checks would be useful to capture before changing anything else:
I would avoid posting private repo URLs or tokens publicly, but the redacted output should make it clearer whether this is mainly a partial-clone recovery issue or a v0 Git workspace identity issue.