cjson CI flake: cJSON.c downloaded from raw.githubusercontent.com at test time

## What happens

The `cjson` fixture jobs download `cJSON.c` from `raw.githubusercontent.com` during fixture setup, before any test runs. When that fetch hits a transient network failure, the whole job fails even though nothing in the PR or the generated code is at fault.

## Evidence

- **Signature:** `curl (35) OpenSSL SSL_connect: Connection reset by peer` while fetching `deps/cJSON.c` from `raw.githubusercontent.com` during fixture setup, before any test ran.
- **Affected PR (1):** #2994, which only touches the Haskell renderer and `any.schema` — nothing cjson-related.
- **Also on master:** a related `cjson-default` deps failure appears on master run `29787019161` (merge of #3028), confirming this is environmental.

## Impact

Because the fixture matrix runs with `fail-fast: true`, a single cjson dependency-download failure cancels every sibling language job in the same matrix and trips the `test-complete` gate. See #3066 for details.

## Suggested solutions

- Vendor `cJSON.c` (and its header) directly into the repo — it is only two files — so no network fetch is needed at test time.
- Alternatively, cache the download with `actions/cache`.
- At minimum, add `curl --retry` to tolerate transient resets.

## Interim policy

Per `CLAUDE.md` ("Known CI flakiness"), we accept this flake for now. When it happens we retry the failed jobs (`gh run rerun --failed`); a failure here only counts as real if it reproduces across retries or the PR actually touches cjson.

Locate the cjson fixture setup that fetches deps/cJSON.c from raw.githubusercontent.com, and read CLAUDE.md for the current CI-flake policy. Compare the vendoring, cache, and retry options described in the issue; done means cjson fixture jobs no longer fail from a transient dependency fetch and the affected CI matrix completes successfully.

Written by the indexing model from the issue text.