ci(flaky): test_no_host_paths times out (>120s) under runner I/O stall, aborts whole suite via -x

## Summary `tests/test_no_host_paths.py::test_no_host_specific_absolute_paths` intermittently fails CI with `Failed: Timeout (>120.0s) from pytest-timeout`, even though the test completes in **~0.4s** in isolation. Because the suite runs with `-x` (fail-fast), this single transient timeout aborts the **entire** `call-test-lint` job and red-flags otherwise-green PRs. Observed on PR #755 (`call-test-lint / Test and Lint`, run `28295440326`): every other check passed; the only failure was this timeout. A failed-jobs re-run was triggered to unblock — but the flake will recur. ## Evidence CI failure (truncated): ``` =================================== FAILURES =================================== _____________________ test_no_host_specific_absolute_paths _____________________ ... > text = path.read_text(encoding="utf-8") tests/test_no_host_paths.py:89: ... E Failed: Timeout (>120.0s) from pytest-timeout. ``` Local timing of the same test, same commit: ``` tests/test_no_host_paths.py . [100%] ============================== 1 passed in 0.40s =============================== 0:00.75elapsed ``` The test is a plain regex sweep over a few hundred small `.py` files. There is no operation in it that can legitimately take 120s. The traceback shows it blocked inside `f.read()` on a small file — consistent with a transient runner I/O stall, not a code defect. ## Root cause (mechanism) In `pyproject.toml`: ```toml [tool.pytest.ini_options] addopts = "-v --cov=strands_robots --cov-report=term-missing --strict-markers --timeout=120" ``` and `.github/workflows/test-lint.yml` runs `hatch run test -x ...`. - `--timeout=120` is a single **global per-test** budget. pytest-timeout's default method measures full wall-clock (including fixture setup and coverage instrumentation), so under runner I/O contention any one test can momentarily exceed it. - `-x` makes that one transient timeout abort the whole suite. So a millisecond-scale hygiene test becomes a full-CI failure whenever the runner hiccups. This gets worse as the repo grows (more files to walk, larger coverage flushes). ## Proposed fix (smallest viable) Decouple a transient stall from a hard suite failure. Options, in order of preference: 1. **Pin a generous timeout marker on the I/O-bound sweep test** rather than relying on the global 120s — e.g. mark `test_no_host_paths.py` with `@pytest.mark.timeout(0)` (disable) or a large value, since it is a deterministic hygiene check whose slowness is purely environmental, not algorithmic. This is the most surgical change. 2. Raise the global `--timeout` modestly (e.g. 300) to absorb runner I/O jitter without masking genuine hangs. Option 1 is preferred: it is targeted, documents intent at the test, and leaves the strict 120s budget protecting the rest of the suite. ## Acceptance criteria - The host-paths hygiene sweep cannot fail CI due to a transient runner I/O stall. - Genuine hangs elsewhere in the suite still trip the 120s budget. - No change to what the test actually validates (it must still catch `/Users/<name>/`, `/home/<name>/`, `C:\Users\<name>\`). ## Notes Intentionally filed as a standalone issue rather than folded into PR #755 (an approved, scope-tight hardware feature PR) to keep that diff coherent.