feat(server,cli): expose is_quarantined on test case run API

Follow-up to the conversation on #10730 — a much smaller change that I think cleanly unblocks the CI-UX mismatch we were discussing, without the parse-cost concern.

Summary

The test_case_runs ClickHouse table already captures is_quarantined per row at ingest time (server/lib/tuist/tests/test_case_run.ex:51). This PR just exposes that value on the list and show API responses.

Unlike the parent test case’s live state, the value on a run row is a snapshot at ingest time, so it stays accurate if the test’s quarantine state changes later. That’s exactly the signal CI post-processors need to tell real failures apart from quarantined ones for a specific run.

Why

We’re trying to reconcile the CircleCI Tests tab (which shows every failing <testcase> regardless of quarantine) with tuist test’s final verdict (which treats quarantined-only failures as green). Today we fetch the current quarantined-test list separately and cross-reference by test identity. That works, but:

• It’s indirect — it tells us “quarantined now,” not “was quarantined at the time this run executed.”
• It requires a second API call on top of whatever we already do to enrich the JUnit.

With is_quarantined on the run row itself, a consumer can get the answer from the same API call that gives them the failure details.

Changes

Server:

• server/lib/tuist_web/api/schemas/tests/test_case_run.ex — add is_quarantined to the shared list-row schema.
• server/lib/tuist_web/controllers/api/test_case_runs_controller.ex — add is_quarantined to both the list response body and the show response body + inline schema, and mark it required.
• server/test/support/tuist_test_support/fixtures/runs_fixtures.ex — let test fixtures set is_quarantined (defaults to false for backward compatibility with existing tests).
• server/test/tuist_web/controllers/api/test_case_runs_controller_test.exs — add assertion for the default false case and a dedicated test covering is_quarantined: true across both list and show.

CLI (regenerated client):

• cli/Sources/TuistServer/OpenAPI/server.yml + cli/Sources/TuistServer/OpenAPI/Types.swift — add is_quarantined to the shared TestCaseRun schema and the getTestCaseRun response payload. I hand-applied just the is_quarantined additions rather than running server/mise/tasks/generate-api-cli-code.sh end-to-end, because running the generator locally picks up unrelated drift between the committed server.yml and the current server source (e.g. account:scim:write scope, PUT→PATCH on test-cases/{id}). Happy to swap for a full regen if you’d like that drift reconciled here instead of in a separate cleanup PR.
• cli/Sources/TuistServer/Services/GetTestCaseRunService.swift + cli/Sources/TuistServer/Services/ListTestCaseRunsService.swift — extend the DEBUG-only .test() factories so they accept isQuarantined, defaulting to false to preserve existing call sites.

How to test locally

cd server
mix test test/tuist_web/controllers/api/test_case_runs_controller_test.exs

CLI builds green locally via tuist generate --no-open && xcodebuild build -workspace Tuist.xcworkspace -scheme tuist. Test target also builds.

Notes

• Zero change to ingest or to any existing data.
• Purely additive to the API response; existing consumers that ignore the field are unaffected.