Fix CI workflow to fail Test job on pytest failures (ar-r82f.16)

[atc964]

Summary

The CI Test job was silently passing on failing pytest runs. Discovered on
PR #14's run 26593648988:
pytest reported 5 failed, 709 passed but the Test job concluded success.

This means all recent "green CI" claims on main may be unreliable.

Root Cause

The Unit tests / Integration tests steps wrapped pytest in a shell timeout
with exit-code mapping:

set +e
timeout --kill-after=10s 60s pytest tests/unit/ -v --tb=short
code=$?
([ $code -eq 124 ] || [ $code -eq 137 ]) && exit 0 || exit $code

The intent was to swallow only true timeouts (124) or SIGKILLs (137).
In practice, pytest itself completes quickly (~9s), but the python interpreter
then hangs for ~50s during shutdown cleaning up crewai telemetry threads
(cannot schedule new futures after interpreter shutdown log spam).

The 60s shell timeout was firing during that shutdown hang, killing the
interpreter with SIGTERM, returning exit code 124. The workflow then mapped
124 to exit 0 — even though pytest had already printed 5 failed, 709 passed
before the kill.

Timeline from run 26593648988 (Unit tests, py3.12):

• 18:19:34 — step started
• 18:19:45 — pytest done, reported 5 failed, 709 passed
• 18:20:34 — interpreter still hanging on crewai telemetry shutdown
• 18:20:35 — 60s timeout fires → SIGTERM python → exit 124 → mapped to exit 0
• Step concluded: SUCCESS

Fix

Drop the shell timeout wrapper entirely. Use pytest-timeout for per-test
deadlines (30s unit, 60s integration). Pytest's exit code now propagates
directly to GitHub Actions.

Changes:

• .github/workflows/ci.yml: replace the set +e ... timeout ... exit code mapping block with pytest --timeout=N for both Unit tests and Integration tests steps.
• pyproject.toml: add pytest-timeout>=2.3.0 to dev deps.

Verification

Done with deliberate failure injection on this branch.

1. Pushed the fix commit alone → expect green CI on this branch's first push.
2. Added a poison-pill commit (tests/unit/test_ci_poison_pill_DELETEME.py)
   with assert False → expect CI Test job to conclude FAILURE (the whole
   point of this PR).
3. Watch the poison-pill run conclude red.
4. Revert the poison-pill commit → expect green CI again.

Verification status will be appended as commits and CI runs land.

Test plan

• Workflow committed and pushed
• Poison-pill commit causes CI Test job conclusion = FAILURE (proves fix works)
• Poison-pill reverted, CI Test job conclusion = SUCCESS (proves no regression)
• Final state: ci.yml fix + pytest-timeout dep, no poison-pill in tree

Bead

ar-r82f.16 — Fix seller-agent CI: workflow silently passes on failing tests

[atc964]

Status — parked, not closing

Today's work proved this PR's workflow change is functionally correct — it surfaces real pytest failures (verified by cycle 1: poison-pill present → CI conclusion FAILURE in 8.47s). The previous workflow silently passed those failures, which is the bug this PR is fixing.

Why not merging tonight: seller-agent CI has a second, independent issue — a Python interpreter shutdown hang after pytest exits cleanly. Cycle 4 evidence (run 26599023320):

• Lint: ✅ PASS
• Pytest: ✅ PASS (719 passed in 7.63s)
• Then: 591 seconds of dead-air post-pytest until the outer 600s timeout killed the process with exit 124
• CI conclusion: FAILURE

If we merge this PR as-is, every subsequent seller-agent PR would fail CI on this same hang regardless of test results — strictly worse than the current (buggy, silent-pass) state.

Diagnosis (via ar-r82f.21): root cause is CREWAI_TELEMETRY_OPT_OUT being a no-op env var in crewai 1.14.6 (only OTEL_SDK_DISABLED, CREWAI_DISABLE_TELEMETRY, CREWAI_DISABLE_TRACKING are recognized). Even with all those set plus extra downstream-dep opt-outs (chromadb, posthog), the hang persists — meaning some other transitive-dep daemon thread is keeping the process alive past pytest exit.

Path to merge:

1. Land ar-r82f.21: write a monkey-patch shim in seller-agent (and likely buyer-agent) that unregisters the offending atexit handlers on import, OR file upstream issue with crewAIInc/crewAI for a real fix.
2. Rebase this PR onto post-ar-r82f.21 main.
3. Re-run CI — should be SUCCESS.
4. Then merge.

Moving to Draft for clarity. Branch and 600s+telemetry-env workflow changes are preserved — when ar-r82f.21 lands this can be picked up directly.

cc bead: ar-r82f.16 (blocked-by ar-r82f.21)