test(turbodocx-sdk): add getRecipients evals for Python, Go, PHP and Ruby

[nicolasiscoding]

Related

Closes #19

Follows #18, which added getRecipients to all six language references but eval cases for only two of them.

Description

getRecipients shipped into every language reference in #18, but the eval suite only covered Express (id 45) and Spring Boot (id 46). Python, Go, PHP and Ruby had documentation with nothing testing it — a wrong method name or a dropped await in those templates would ship unnoticed.

This adds ids 50–53 for FastAPI, Gin, Laravel and Rails, modelled on 45/46, using each SDK's real method shape:

id	Stack	Call asserted
50	FastAPI	await TurboSign.get_recipients(document_id)
51	Gin	GetRecipients(ctx, documentID)
52	Laravel	getRecipients($documentId)
53	Rails	get_recipients(document_id)

What every case asserts

Both failure modes that produce working-looking but wrong code:

• getRecipients, not getStatus. getStatus returns only { status } — the document-level state — so it cannot answer who signed. Code using it compiles, runs, and answers a different question than the user asked.
• Branch on effectiveStatus, not status. There is no per-recipient declined/voided/expired state, so on a voided or expired document an unsigned signer still reads pending in status. Generated code branching on it chases people whose signing links are already dead.

Per-language traps pinned

• Python (50) — awaits-the-call. The method is async; a bare call returns a coroutine rather than the roster, which fails at runtime rather than at author time.
• Go (51) — passes-context and handles-error-return. The signature takes context.Context first and returns (result, error); a discarded error hides the failure entirely.

Validation

• evals.json parses; all 53 ids unique.
• New cases match eval 45's field set exactly (id, prompt, expected_output, files, assertions).
• Every assertion uses a type already in use in the file (file_contains).
• files lists follow the existing per-framework convention (e.g. pyproject.toml + app/main.py for FastAPI, go.mod + main.go for Gin — matching ids 44 and 9).

I did not execute claude evals run evals/evals.json — it drives 53 agentic runs, which is a long and costly operation better done in whatever environment normally runs the suite. The changes here are data-only (no skill or reference logic touched), so nothing in this PR can change the outcome of the existing 49 cases.

Note on the underlying behaviour

The endpoint these evals describe was exercised end to end on staging through a full document lifecycle — sent → resent → viewed → signed — with 16/16 assertions passing at each step. So the semantics asserted here (effectiveStatus transitions, delivery.totalSent counting real sends only, waitingOn reaching 0 only at completion) are confirmed against a live endpoint rather than inferred from the SDK types.