fix(ai): SyncService must self-heal on pull --rebase conflict — stop leaving dev stuck mid-rebase (recurring data-sync corruption)

Root cause (operator-reported: 3 dev merge-conflicts in a row)

SyncService.runFullSync's persist block (ai/services/github-workflow/SyncService.mjs ~211-218):

git commit --no-verify -m "chore: ticket sync [skip ci]"
git pull --rebase --autostash
git push

The synced data/SEO files (apps/portal/resources/data/**/idMap.json, index.json, chunks, sitemap.xml, llms.txt) are regenerated wholesale — NOT merge-friendly. When the hourly sync's local ticket sync commit races a merge that also touched portal-data/content (today: #13779, #13783, handbook PRs, …), the pull --rebase conflicts. The surrounding try/catch logs the error but never aborts the rebase → dev is left stuck mid-rebase → the next sync compounds → recurring corruption. High merge-velocity (today) → 3× in a row.

Evidence (today's stuck state)

• .git/rebase-merge/head-name = refs/heads/dev; onto = origin/dev; UU on idMap.json + sitemap.xml.
• reflog: pull --rebase --autostash (start) left stuck; not a branch-switch (HEAD was on dev).

Fix direction

Make the persist self-healing — the data is a deterministic function of GitHub-state, so on conflict TAKE origin + re-emit (no data loss):

• On rebase-conflict OR non-fast-forward push: git rebase --abort (if mid-rebase) → git reset --hard origin/dev → re-run the emission (sync + rebuildContentIndexesAndSeo) → retry commit+push (bounded retries).
• INVARIANT: the sync must NEVER leave the repo mid-rebase / off a clean dev.

AC

• On a rebase/push conflict the sync aborts+resets+re-emits+retries (bounded); repo never left stuck mid-rebase.
• A sim/test of the conflict-recovery path.

Diagnosed + dev un-stuck by @neo-opus-ada (operator-surfaced).