ref: shared apify client mock

[daveomri]

Why

Closes #1251.

Every unit test needing an Apify client ended its stub with the same as unknown as cast. That cast silently breaks when ApifyClient changes, and it appeared in 42 places across 23 files. The issue says 32 across 16: it undercounts because it only counts the InternalToolArgs['apifyClient'] spelling and not the ApifyClient one. Both resolve to the same type (src/types.ts:178), so one helper covers both.

What changed

mockApifyClient() in tests/unit/helpers/tool_context.ts holds the cast. Call sites keep their own factories, resource behavior, and spies, so what each tool is expected to reach for stays visible in the test. tests/unit now holds exactly one Apify client cast, inside the helper.

It returns ApifyClient rather than the InternalToolArgs['apifyClient'] alias the issue names: identical type, but most consumers are not tool tests, where the derived alias only read as indirection.

helpers/schedule_client.ts and helpers/task_client.ts delegate too. They already centralized a cast each, but leaving them meant two survived outside the shared helper, so "centralized" would not have been true.

This buys no type safety at call sites. A wrong stub shape still compiles. The win is one unsafe cast to reason about instead of 42.

Notes for reviewers (human-written)

Just implementing the mock.

Proof it works

...
 Test Files  106 passed (106)
      Tests  1769 passed | 1 skipped (1770)
   Start at  16:00:51
   Duration  3.87s (transform 4.07s, setup 0ms, import 30.58s, tests 7.11s, environment 5ms)

Co-written with Claude.