R1 — Timeouts are explicit

Every outbound call to an external service or DB has an explicit timeout configured - no reliance on library/socket defaults.

R1: every outbound call to an external service or DB has an explicit
timeout configured. rubric_store/definitions/reliability.yaml tags this
fully static_analyzable and marks it critical severity — a missing timeout
is the classic cause of cascading failures called out directly in
otel_telemetry_diagnostician_skill.md's failure-pattern list.

Fail-branch confidence retuned from 0.9 to 0.154, per
docs/false_positive_rate_study_v1.md: a hand-labeled sample scored 0/9
correct, for the same shared root cause as T1 (the `outbound_call`
construct matches any `object.method(...)` call, not just genuine outbound
calls) — pooled across Python/Java/Go since the study confirmed this
reproduces identically in all three. The pass-branch confidence (0.9) is
untouched; a real `timeout=` keyword argument is a specific positive
signal the study did not find reason to doubt.

R1 for Java: outbound call has a timeout configured. Java has no keyword
arguments, so unlike the Python version this checks for a nearby builder
call (.timeout(...), .connectTimeout(...)) in the enclosing method rather
than an argument on the call itself — see ast_helpers.has_nearby_timeout_call.

R1 for Go: was a context.WithTimeout/WithDeadline call made earlier in
the enclosing function? Same textual-precedence tradeoff as T1 — Go
timeouts are usually enforced via a context passed down, not an argument
on the call itself, so this can't be a direct argument check the way the
Python version is.