Centralize shared test doubles and fixtures for core CPU tests

[kasikci]

Context

Several tests build their own mocks, fakes, and setup helpers for common mstar
components, including the engine, worker, and API server data worker. Repeated
setup makes tests harder to maintain and can let their assumptions about the
same component diverge.

This follows Naomi's review of PR #306
and the agreement to take on this work after defining the full core CPU test set.

Prerequisite

Determine the full core CPU test set first. Use that agreed set to decide which
shared helpers to extract and which tests to migrate.

Proposed work

• Inventory repeated test doubles and component setup across the agreed suite.
• Extract small, reusable helpers and pytest fixtures for recurring needs,
  starting with helpers used by multiple included modules. Give each test fresh
  state and explicit control over responses, failures, and recorded calls.
• Migrate one group of tests at a time, preserving their existing assertions and
  the production methods and constructors they exercise.
• Document where shared helpers live and how to reuse or extend them.

Initial candidates to audit, subject to core-suite membership:

• Engine readiness and scheduler collaborators in
  test_tp_follow_targeted_gate.py, test_tp_async_follow_sched.py, and
  test_micro_scheduler.py.
• Worker and recording-communicator setup in test_worker_drain.py and
  test_request_failure_propagation.py.
• API server data-worker (PreprocessWorkerThread) setup in
  test_worker_drain.py, test_request_failure_propagation.py, and
  test_api_completion_guard.py.

Acceptance criteria

• Shared setup is reused by multiple core test modules; specialized behavior
  remains explicit in the tests that need it.
• Migrated tests preserve existing coverage and failure assertions, and pass
  individually and together through the shared CPU test list.
• Tests run on CPU without GPU dependencies, model downloads, or unexpected
  skips, and retain the suite's fast runtime.
• Fixtures isolate mutable state and clean up threads/resources reliably.
• Helper changes remain scoped to the relevant tests, preserving GPU and
  integration-test setup and production behavior.
• Contributor documentation includes a small usage example.