Add deterministic Zendesk Support ticket mock

[reacher-z]

Why

RealReplicaBench currently covers storefront, marketplace, documents, email, and several business CLIs, but does not yet have a customer-support ticket surface. This contribution stages an offline support-desk API that can support realistic triage, assignment, escalation, comment, and status-transition tasks.

What this adds

• A dependency-free HTTP service under real_replica_bench/mock_services/contrib/zendesk_support.
• Synthetic users, organizations, groups, tickets, comments, and closed-set custom fields.
• Authenticated ticket list/search/read/create/update endpoints.
• Server-side validation for assignee roles, references, tags, custom fields, and ticket status transitions.
• A verifier-only state/audit/reset/seed surface separated from the agent token.
• Seed-owned logical timestamps and ID counters; failed mutations roll back atomically.
• A CONTRIBUTORS.md staging entry as required by the contribution guide.

The proposed listen port is 3117. It does not collide with a currently registered mock.

Data and assets

All implementation and fixture content is original. The mock contains no copied source, captured responses, logos, screenshots, fonts, or other third-party assets. Seed identities and records are synthetic and use example.test addresses. The README explicitly states that the project is not affiliated with or endorsed by Zendesk.

Validation

• npm test: 7 integration tests passed
• python scripts/validate_release.py under Python 3.12: passed with 0 warnings
• python -m unittest discover -s tests: 25 tests passed
• python -m compileall -q real_replica_bench scripts: passed
• bash -n for every scripts/*.sh file: passed
• git diff --check: passed

The integration tests cover token separation, filtering/search, deterministic create/update behavior, invalid-request atomicity, reference validation, comments and audit evidence, allowed status transitions, closed-ticket immutability, and exact reset behavior.

Benchmark comparability

This lands only in contrib staging. It is not registered, copied into the runtime image, or referenced by a task, so it does not alter the 107 current tasks or any published result. Promotion and task construction can remain a separate release-boundary change.