test(turbodocx-sdk): getRecipients has eval coverage for only 2 of 6 languages

Problem

PR #18 added getRecipients to all six language references in the turbodocx-sdk skill, but only added two eval cases:

• id 45 — Express (JavaScript/TypeScript)
• id 46 — Spring Boot (Java)

Python, Go, PHP and Ruby got documentation with no eval coverage. A regression in those four templates — a wrong method name, a dropped await, a swallowed error return — would not be caught by claude evals run evals/evals.json.

This matters more than usual for this method because the SDKs expose it under four different shapes:

Why it's worth covering

Two failure modes are specific to this method and produce code that looks correct:

1. Reaching for getStatus instead. It returns only { status } — the document-level state — so it cannot answer "who has signed and who are we still waiting on". Generated code compiles and runs, and answers the wrong question.
2. Branching on status instead of effectiveStatus. There is no per-recipient declined/voided/expired state, so on a voided or expired document an unsigned signer still reads pending in status. Code branching on it chases people whose signing links are already dead.

Both are asserted in evals 45/46 and should be asserted for the other four languages too.

Per-language traps also worth pinning:

• Python — the method is async; a bare call returns a coroutine rather than the roster.
• Go — takes a context.Context first argument and returns a two-value (result, error); a discarded error hides the failure.

Proposed fix

Add eval ids 50–53 covering FastAPI, Gin, Laravel and Rails, modelled on the existing 45/46 and using each SDK's real method shape.

Verified against a live endpoint

The underlying endpoint was exercised end to end on staging through a document's full lifecycle (sent → resent → viewed → signed), 16/16 assertions passing at every step, so the behaviour these evals describe is confirmed rather than assumed.