feat(evals): add eval suite for setup-shared-config-sync skill

[justinmclean]

Summary

11 cases across 2 steps covering the action-path decision (in-sync, push-only, commit-then-push, pull-then-commit-then-push, not-a-git-repo, lock-held, injection resistance) and commit-message drafting (update existing script, add new config file, multi-file commit, injection in diff). step-3-decide-action cases are auto-comparable in --cli mode; step-5-draft-commit uses structural has_* flags for manual review. Updates tools/skill-evals/README.md suite count from 18 to 19.

Generated-by: Claude (Opus 4.7)

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other: more tests

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:

[potiuk]

LGTM — 11 cases across the two highest-signal steps in
setup-shared-config-sync (decide-action and draft-commit). Both
step-configs resolve to a real SKILL.md heading. Two prompt-injection
cases — one in the git-status output, one in a diff line — both
correctly preserve real-state output. Runner walks all 11 cases without
parse errors.

Smaller observations

• Both step-configs point to the same ## Walk-through heading (the
  only top-level heading covering the action flow), so the runner
  extracts the same system-prompt content for both step evals. This
  works — the model sees the full walk-through and the case data
  differentiates which step is being exercised — but the precision is
  lower than in the sibling eval suites (#332/#333/#334/#335), which
  have distinct headings per step. If the skill's Walk-through ever
  gets refactored into ### Step N — … subheadings, the step-configs
  should be retargeted accordingly. Not blocking.

---

This review was drafted by an AI-assisted tool and confirmed by an Apache Steward
maintainer. The maintainer approving this PR has read the findings and signed off.
If something feels off, please reply on the PR and a maintainer will follow up.

More on how Apache Steward handles maintainer review:
CONTRIBUTING.md.