Add "Sync with Door43" for shared/collaborative projects

[deferredreward]

Fixes #7667

What

Adds a per-project Sync with Door43 action (in the project card menu, next to Upload) that pulls the latest changes from the project's Door43 repo, merges them with local checking work, and pushes the combined result back — enabling multiple people (or one person on multiple machines) to work on the same shared Door43 project. Today the only push-side action is Upload, a plain git push that aborts on non-fast-forward with no way to reconcile.

How

A raw git merge is not viable for tC data (thousands of timestamp-named JSON check-data files would conflict constantly with no resolution UI), so sync uses a data-level merge built on the existing project-overwrite machinery:

1. Commit local state (same steps as upload: unlock, save changes, USFM3 export, commit).
2. Fast path: get the remote HEAD sha (getRemoteRepoHead) and, if it is already an ancestor of local HEAD (new GitApi.isCommitInHistory), just push — no clone or merge. Cheap for the two-machines-one-user case.
3. Otherwise clone the remote fresh into the imports area, verify/migrate it, and merge the local project into the clone (ProjectSyncHelpers.mergeLocalIntoRemoteClone): local check data is the base, remote-only check data is unioned in (timestamp filenames make file-level union safe), remote alignments are overlaid per verse (reusing copyAlignmentData), manifest checkers/translators are unioned, and external verse edits are recorded with stale selections invalidated (reusing createVerseEditsForAllChangedVerses). For verse text, the Door43 copy wins — disclosed in the confirmation dialog.
4. Keep the clone's git history so the post-merge commit fast-forwards, swap it into place with a .sync_backup for failure recovery, then push to the origin owner's repo using the logged-in user's token (new GitApi.pushRepo) so collaborators can push to a shared repo.

Edge cases handled: offline / not logged in (same guards as upload); project never uploaded (offer Upload); remote repo deleted (offer re-upload); push race — remote changed mid-sync (prompt to sync again); permission denied (new GIT_ERROR_PUSH_DENIED mapping → suggest collaborator access or an own-copy upload).

Files

• New src/js/actions/ProjectSyncActions.js, src/js/helpers/ProjectSyncHelpers.js
• GitApi.js: pushRepo (generalizes pushNewRepo to any owner/name), isCommitInHistory
• Repo.js: GIT_ERROR_PUSH_DENIED + mapping in convertGitErrorMessage
• ProjectUploadActions.js: export makeSureProjectUnlocked
• Sync menu item (ProjectCardMenu/Menu.js + index.js); ~10 new projects.* locale keys + buttons.upload_button (English only; other locales via Crowdin)

Testing

• New ProjectSyncHelpers.test.js (6 tests: checkData union, alignment overlay, .git preserved, manifest union, no-remote-apps copy), new ProjectSyncActions.test.js (guard cases), extended GitApi.test.js (pushRepo, isCommitInHistory). Also added the missing fs.writeJsonSync alias to the fs-extra test mock (it only had writeJSONSync, so copyAlignmentData's writes were silent no-ops under test). All touched suites pass (ProjectSyncHelpers, ProjectSyncActions, GitApi, Repo, ProjectUploadActions, ProjectCardMenu); eslint clean.
• Not verified in this PR: a live end-to-end round-trip against Door43 (two clients editing the same repo, merge + push, permission-denied and push-race paths). The merge helpers and git primitives are unit-tested, but the full flow against a real DCS repo should be exercised during review. The interactive validation stepper is intentionally skipped for synced content (MVP); per-verse text conflict UI, org repos / non-master branches, and an auto-sync indicator are noted as follow-ups.

🤖 Generated with Claude Code