gh simulator (3/3): api, fault injection, and one mock for lib.test.sh #88

Category: feature
Area: Evaluation (tests/)
Impact: This part is what makes a run a test: failures can be injected, api is covered, and there is one gh mock, not two.
Confidence: traced

Part 3 of 3 of #60.

Problem (the use case)

lib.sh and the skills call gh api for comments, files, contents and update-branch. A maintainer cannot inject a failure (a merge GitHub rejects, a check that never finishes). tests/lib.test.sh keeps its own gh stub next to the simulator.

Proposed solution

• api: user, repos/{owner}/{repo}/issues/N/comments (--paginate), pulls/N/files, contents/<path>?ref= (raw Accept header), git/trees/HEAD?recursive=1, and the update-branch PUT, with the few --jq reads the skills make.
• Fault injection: a world file (so a scenario) may carry faults: [{match: "pr merge", fail: "not mergeable"}]. A matching call exits non-zero with that message, changes nothing, and is marked as a fault in the log. times limits how often it fires.
• Replace the stub in tests/lib.test.sh with the shared simulator and keep all 154 tests passing. There is one mock.
• Tighten the manifest test: no command may stay planned.

Acceptance criteria

• Every gh command the skills use is supported, and an unsupported one fails loudly. The manifest test fails on a planned entry.
• tests/lib.test.sh runs against the shared simulator and still passes (154 tests).
• A fault can be injected and is visible in the call log.
• Any scenario's world can seed a run.

Non-goals

Matching GitHub beyond what the skills depend on. A runner that drives a model (#61).

Blocked by: #87