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.

.github/workflows/sync-branches.md と .github/workflows/sync-branches.lock.yml を削除することから始め、続いてリポジトリ内でドキュメントと手順にある sync-branches の参照を検索します。autoloop.md Step 3 を読み、ブランチの鮮度の扱いについて引き続き説明していることを確認します。両方の workflow ファイルと古いドキュメント参照が削除され、Step 3 の変更が不要であれば完了です。

索引モデルが issue の本文から書いたものです。