Give valgrind-wrapped leak tests a minimum timeout ##r2r

[phix33]

• Mark this if you consider it ready to merge
• I've added tests (optional)
• I wrote some lines in the book (optional)

Description

A <leak> test derives its per-test budget exactly like a plain cmd test (run.c:1765 vs :1328) and is then wrapped in valgrind, so one wall-clock budget covers two execution modes ~40x apart. Measured on db/leak/open's slowest case (r2 -AA bins/dotnet/HelloWorld.exe): 0.55s native, 22.0s wrapped. The analysis itself is not slow — 285 KB/s vs 393 KB/s for elf/ls — it is just the largest binary in db/leak.

Invisible at the 3600s default, which is why it has gone unnoticed. It bites any budget that is sane for the ~17k native tests:

r2r -L -u -t 15 test/db/leak/open     before: 12 OK  1 XX (TIMEOUT)
                                      after:  13 OK  0 XX

Fix is a floor, not a multiplier: leak tests get at least 120s (5.5x the slowest measured), whatever the budget's source. A multiplier was tried first and rejected — the leak job runs with no -t (tcc.yml:242), so 3600s x 40 would have removed the reaper rather than widened it.

Verified: -t 0's "no timeout" sentinel survives (a floor only ever raises); a leak test too slow to finish is still reaped, at 120.0s; no change at the default budget; lint and -Wall -Werror -O2 clean; full r2r gate vs master 0 regressions.

The floor also applies to an explicit per-test TIMEOUT= — deliberate, since a sub-120s budget cannot be met under valgrind and would only produce a false failure. Happy to make it default-path only if you prefer.