sync silently ignores remotes without a collab refspec, and reports the count as complete

open   by a73x

A remote you added is excluded from `sync` with no diagnostic, and the summary counts as if it were the whole set.

Reproduced in a repository with two remotes:

```
$ git remote
a73x
origin

$ git-collab sync
Sync incomplete: 1 of 1 remote(s) failed.
  Failed:    'origin'
```

**"1 of 1"** with two remotes configured. `a73x` is not reported as failed, skipped, or unconfigured — it is absent, and the count reads as complete.

Cause: `collab_remotes` selects only remotes carrying a `+refs/collab/*` fetch refspec, which `git-collab init` adds. A remote added *after* `init` has none, so it is filtered out. The doc comment justifies this — "syncing it would just fail on refs that were never meant to travel there" — and that reasoning is sound for a remote that has nothing to do with collab. It is wrong for the common case: you add a second remote precisely because you want your work on it, and the tool quietly disagrees.

The fix is `git-collab init` (idempotent since 7824bd7b), which is not discoverable from anything the tool says.

Wanted:

- **Say something.** `sync` knows the repository's full remote list and its own filtered list; when they differ, name the difference: `note: remote 'a73x' has no collab refspec and was not synced — run `git-collab init` to include it.`
- **Make the count honest.** `1 of 1` should be `1 of 2, 1 not configured`, or the total should be the repository's remotes.
- Consider whether `sync --remote a73x`, naming a remote explicitly, should configure it or at least refuse with the reason rather than behaving as though the request were ordinary. Explicitly naming a remote is a clear statement of intent.

Reported by the user, who reasonably read the behaviour as "git-collab only syncs to origin". From the outside that is exactly what it looks like.