Remove sync-branches workflow — broken on this repo and redundant with per-iteration branch hygiene (#179)

## Summary

Delete `.github/workflows/sync-branches.md` and `.github/workflows/sync-branches.lock.yml`. The workflow is currently broken and doing no useful work.

## Current state — it doesn't work

Every recent run of sync-branches is failing. Two overlapping problems:

1. **Lock-file drift.** `sync-branches.md` has been edited without running `gh aw compile sync-branches`, so the activation step bails out with:

```
##[error]ERR_CONFIG: Lock file '.github/workflows/sync-branches.lock.yml' is outdated!
The workflow file '.github/workflows/sync-branches.md' frontmatter has changed.
Run 'gh aw compile' to regenerate the lock file.
```

2. **Even if we re-compiled it, it wouldn't push.** The workflow declares `permissions: read-all` (to pass gh-aw's strict-mode compile check); that compiles to an empty `permissions: {}` in the lock file; which means the default `GITHUB_TOKEN` has **no** write access. No `GH_AW_GITHUB_TOKEN` PAT is configured in this repo (`gh secret list` returns empty). Any `git push` attempt would be rejected with 403.

The Python script uses `capture_output=True` and appends to a `failed` list — it does **not** fail the workflow on push errors. So before the lock-file drift, the workflow was silently reporting green while syncing zero branches.

## Why we don't need it anyway

The per-iteration Step 3 logic in `autoloop.md` (landed in #179) already does the fast-forward-when-ahead=0 or merge-when-diverged on the program's branch at the **start of every iteration**. That's the same work sync-branches was meant to do between iterations — except it happens on the branch that's actually about to be iterated, at the moment it's needed, with the agent on hand to resolve any merge conflicts.

Roles that sync-branches was theoretically still doing:

| Role | Why it doesn't matter |
|---|---|
| Bring paused programs' branches current | They're paused — no one's iterating on them. |
| Surface merge conflicts before iteration | Iteration's Step 3 surfaces them the same way, on the branch that's about to be touched. |
| Remove "N commits behind" UI banner between iterations | Cosmetic. |
| Propagate main's fixes faster than the program's schedule | The schedules are 30 min and 6 h — fast enough. |

None of these justify a broken workflow that's also fighting strict-mode compile and token permissions.

## Concrete removal

1. `git rm .github/workflows/sync-branches.md .github/workflows/sync-branches.lock.yml`.
2. Audit for any references. Likely candidates: docs, READMEs, `install.md`-style instructions. Remove or rewrite to point at the per-iteration Step 3 as the branch-freshness mechanism.
3. Commit, open a PR.

That's the entire change. No agent prompt updates needed — `autoloop.md` already owns branch freshness via Step 3.

## Follow-on

File the same removal upstream (already tracked — see cross-reference below). Once upstream drops it too, future installs won't re-introduce the broken workflow.

## Acceptance

- `.github/workflows/sync-branches.md` and `.lock.yml` are gone from this repo.
- No references to sync-branches remain in docs.
- The autoloop program iteration still brings its branch current at Step 3 (no regression — verify with the next scheduled run on any active program).

## Related

- Per-iteration branch hygiene: #179 (fast-forward when ahead=0).
- Upstream removal tracking: proposed on `githubnext/autoloop` — will be linked once filed.
- Historical: sync-branches's lock-file drift symptom has been showing up in recent workflow runs for days; removal rather than re-compile is the right resolution.