No minimum git version is asserted or documented; on git < 2.24 every operand-taking verb fails with an opaque "unknown option" error #164

Plan

docs/superpowers/specs/2026-08-19-gitintegration-v2-design.md L660,`` Risks table:

git output format drift between versions | Parse only documented machine formats; pin with fixtures; assert a minimum git version

What exists today

• Every verb that uses AppendOperands (GitCommandBuilder.cs L80-92) emits --end-of-options, which git added in 2.24. GitRestoreBuilder.cs L46-47 acknowledges this dependency.
• The only version probe is the 2.41 check in GitFetchBuilder, which falls back to a less detailed result below 2.41 rather than refusing to run.
• Neither README.md nor CLAUDE.md states which git versions are supported.

Why it matters

On an older git, such as some enterprise distros or Git for Windows installs, every operand-taking verb fails with git's own unknown option complaint, wrapped in a generic GitException. The caller gets no signal that the real problem is the installed git version.

What's missing

A stated minimum version, and a check that fails with a clear, typed error naming the required version. For example, a lazy version probe cached per IGitRunner/client, run on first use or in GitClient.OpenAsync/DiscoverAsync.

Acceptance criteria

• The README states the minimum supported git version.
• Running against an older git raises a specific, documented exception whose message names the required and detected versions, instead of an unknown option error.
• A test drives the check through a scripted runner that returns an old git version string.

Dependencies

None. It is loosely related to open #158 (Apple git version-string parsing), which affects how an Apple git compares against the minimum.