sync: report identifying config context (repo/group/config file) on success and failure

[Odilhao]

Problem

When sync fails partway through a repo, the failure is hard to trace back to the config entry that caused it — and the report gives no way to confirm which config file was even in play, on success or failure alike.

Concretely, today:

• RepoResult (internal/sync/run.go:62) and the RepoEvent emitted to ProgressCallback carry a repo Name and Path, but no group name — so two repos with the same name in different groups can't be told apart from the failure alone.
• cmd/git-manager/main.go's printReport prints r.Path on the success (OK) branch but not on the FAIL branch (main.go:236-241) — the one piece of output most useful for locating a misconfigured repo is dropped exactly when it's needed.
• Some lower-level errors already include useful context (clone.go:36 includes URL and path, remotes.go/branches.go include repo path and remote name), but others don't: identity.go:74's signingMethodConfig returns a bare sync: invalid signing_method %q with no repo, group, or path — so a typo'd signing_method in one repo's config produces an error string that can't be traced back to which repo has it without manually re-reading the whole TOML.
• The live-progress line added in sync: report progress live by default, add a quiet mode for cron #61 (main.go:130) prints the outcome but not the error text; only the final printReport pass does.
• Neither the human-readable report nor --json output ever states which config file (-config path, or the resolved default) was used to produce the run — on success or failure. When someone has more than one config (e.g. testing a draft alongside their real one, or debugging with -config), the report alone can't confirm which file drove the results being read.

The net effect: on a config with many repos/groups, a single typo (bad signing_method, malformed remote URL, etc.) produces a failure that's correct but not self-locating — the user has to bisect the config by hand to find it. And separately, a report of any outcome — success or failure — can't be traced back to the config file it came from without knowing how the command was invoked.

Done when

• A failed repo's reported error (both the final report and any live-progress output) is enough on its own to locate the offending config entry: at minimum repo name + path; group name where the repo belongs to a group.
• RepoResult/RepoEvent carry the group name the repo belongs to (currently absent from both).
• printReport's FAIL line prints r.Path (and group, if set) the same way the OK line already does today.
• Config-level validation errors that currently have no repo/group context (e.g. signingMethodConfig in internal/sync/identity.go) are wrapped with enough identifying detail (repo name/path, and group if applicable) to be traceable without cross-referencing the TOML by hand.
• The report (both human-readable and --json) states the resolved path of the config file used for the run, regardless of outcome — printed once for the run, not per-repo, on both success and failure.
• --json report output gains the same identifying detail (e.g. a group field on the per-repo result, and a top-level config field with the resolved path) so scripted consumers get the same traceability — without breaking existing consumers relying on the current shape (additive fields, not a rename).
• A test asserts that a RepoResult/printed failure line for a repo with a misconfigured field (e.g. bad signing_method) contains enough identifying detail (name + path, group where applicable) to locate the bad entry — extending the existing error-path coverage in internal/sync/run_test.go.
• A test asserts the resolved config path appears in the report on both a fully successful run and a run with failures.

Out of scope

• Any change to what counts as success/failure/partial for a repo, or to sync.Run's concurrency model.
• Validating config before sync runs (a pre-flight config lint/--check-style pass) — this issue is about diagnosability of a run's results, not adding new validation.
• Retrying or auto-fixing a misconfigured repo.
• Rewording/improving unrelated error messages that already carry sufficient context (e.g. clone.go, remotes.go, branches.go already include path/remote — leave those as-is unless a group name needs adding to match the new shape).
• Printing per-repo config file provenance (e.g. which .d/ fragment a repo came from, relevant to config: support .d/ drop-in fragments for large groups #59) — this issue is about the single top-level config path used for the run, not per-fragment attribution.

Notes

Builds on the progress-reporting infrastructure from #61 (d905bb6): the ProgressCallback/RepoEvent hook already fires exactly where a per-repo failure is known, so this is about enriching what it and the final report carry, not adding a new hook point.