test: Retry CliRunner apply subprocess on timeout to reduce flakiness - #6592

What changed

CliRunner.run() (the helper that runs feast apply in a fresh child interpreter for unit tests) now retries once on subprocess.TimeoutExpired instead of treating the first timeout as terminal. The per-attempt timeout is unchanged (120s); the timeout message now includes the attempt counter.

Why

The unit-test workflow flaked on unit-test-python (3.11, macos-14) while setting up test_feature_server.py::test_push_and_get:

ERROR sdk/python/tests/unit/test_feature_server.py::test_push_and_get
  AssertionError: stdout: b''
  stderr: b"Command timed out after 120s: [\x27apply\x27]"
2259 passed, 47 skipped, 1 error

run() spawns a new Python interpreter (sys.executable feast.cli apply) — deliberately, for feature-repo import isolation — which has to import Feast (pandas/pyarrow/protobuf/...) from cold. On a loaded macOS runner that cold start can occasionally exceed the 120s guard. The same commit passed on macos-14 / 3.12 and on all three Ubuntu legs, which is the signature of an environmental cold-start stall rather than a code fault.

Crucially, commands routed through run() (e.g. apply) do not materialize, so they cannot trigger the Dask atexit hang that run_with_output() and the module docstring describe. A timeout here is therefore almost always transient slowness, not a deadlock — so a single retry with warm OS/page caches clears it, while a genuine repeated stall still fails once the attempts are exhausted. Retries are intentionally not added to run_with_output(), whose commands can legitimately hang and whose existing machinery recovers partial output rather than retrying.

This builds directly on the CliRunner subprocess stabilization in #6560.

Validation

• uv run ruff check sdk/python/tests/utils/cli_repo_creator.py — passed
• uv run ruff format --check sdk/python/tests/utils/cli_repo_creator.py — already formatted
• Retry logic verified by monkeypatching subprocess.run:
  • transient timeout on attempt 1 → recovered on attempt 2 (returncode == 0)
  • always timing out → returncode == -1, message ... (attempt 2/2): [...], no exception raised
  • success on first attempt → exactly one subprocess call (no behavior change for the passing path)

Note: the full unit suite could not be collected on my machine (local venv lacks the google.cloud test extra pulled by conftest.py); the change is confined to the retry loop, which is covered by the targeted verification above.

Separate from #6591 (which surfaced this flake).