validate a public-review stage's model pin against the provider's own model list

[atomantic]

Summary

• A pr-reviewer stage pin outlives edits to its provider's models list. The live Eligibility Gate was pinned to a model its provider no longer offered, and the guard only checked that the pinned provider matched the resolved one — so the stale id reached the CLI as a model it could not serve.
• Consequence: the stage spawned, exited in ~12s with no output, and was retried through a fresh task id — roughly 20 spawns in five minutes, which the churn guard logged a park for on every cycle without stopping.
• resolvePublicReviewAgentProvider now also requires the resolved provider to offer the pinned model, mirroring the check the ordinary resolution path and cliProviderRun.js#resolveCliProviderAndModel already make. A provider that enumerates no models stays a pass-through.

Found while driving the pr-reviewer automation over the five open contributor PRs (all now reviewed and merged).

Test plan

• server/services/agentProviderResolution.test.js — 29/29, with two new cases: a pin the matching provider no longer offers falls back to the provider's own selection, and a pin on a provider that enumerates no models is still honored.
• Bypass probe: forcing pinIsOffered = true fails the new test, confirming it catches the defect rather than restating the implementation.
• prReviewerPipeline.test.js + prReviewerSecurity.test.js — 46/46 together with the above.

Follow-ups filed

• pr-reviewer: a stage agent that produces no output re-spawns unbounded instead of blocking #6124 — the unbounded retry storm an output-less stage causes (the park logs but does not suppress regeneration).
• opencode-ollama-tui provider cannot serve any ollama model — every run fails with UnknownError #6125 — opencode-ollama-tui cannot serve any ollama model on this install; needs a readiness probe so a broken provider reports unavailable instead of failing at spawn.