fix(test): give the async polling helpers a deadline that survives a loaded suite

[windoze95]

Why

TestVideoImport_NativeVideoUsed failed a full-suite run with video import job 1 did not finish in time, then passed 3/3 in isolation and 3/3 in the full package. Nothing was broken — the helper polls a background goroutine against a hard 3-second wall-clock deadline, which is really a timing assertion on the Go scheduler. Under go test ./... (what the CI deploy gate runs) every package compiles and runs at once and a goroutine can be starved well past 3s. On my machine Microsoft Defender was also burning 168% CPU, which is exactly the kind of thing that tips it over.

This matters because that suite is the deploy gate. A gate that reddens at random gets ignored, and an ignored gate is worse than a slow one.

What

Five helpers had 2–3s deadlines, all the same shape (poll until the background work lands, fail on timeout):

File	What it waits for
service/import_video_test.go:187	video import job reaching a terminal state
service/import_video_test.go:473	the quota-refund counter
service/multi_recipe_resolver_test.go:66	multi-recipe resolution
handlers/import_video_handler_test.go:188	the video status endpoint
ws/hub_rooms_test.go:19	hub room teardown

They now share testutil.AsyncDeadline (30s), with the rationale documented in one place.

This costs nothing

None of these is a "prove X does not happen" assertion — I checked all six before touching them. Every loop exits the moment the work lands, so the deadline is never actually waited on in a passing run:

--- PASS: TestVideoImport_NativeVideoUsed (0.32s)   <- against a 30s ceiling
--- PASS: TestVideoImport_FreshExtraction  (0.41s)
--- PASS: TestHubBroadcast_RoomIsolation   (0.05s)

The deadline only bounds how long a genuinely stuck test waits before failing. Raising it trades a slower failure case for a reliable gate.

finder_extraction_fix_test.go already allows 90s and was left alone.

Verification

go test ./... -count=1 green twice; go vet and gofmt clean. I tried to force the flake under synthetic CPU load with the old 3s value, but 28 spinners on 14 cores starved the Go toolchain itself and the run never completed — not a useful experiment, so I verified the property that actually matters instead: the deadline is never reached on a passing run, so the increase is free.

🤖 Generated with Claude Code

https://claude.ai/code/session_0194PdH4wDTnz5SWfzyoKagc

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.