Bridge timeoutMs should be validated to avoid NaN/negative timeouts

[bbopen]

Summary

NodeBridge and OptimizedNodeBridge accept invalid timeoutMs values (NaN/negative). These flow into setTimeout and TimedOutRequestTracker.ttlMs, causing immediate timeouts or NaN TTL behavior that can drop timeout tracking and mis-handle late responses.

Failure mode

• timeoutMs = NaN → setTimeout behaves unexpectedly; TimedOutRequestTracker TTL becomes NaN.
• timeoutMs < 0 → immediate timeout (or clamped), inconsistent behavior.

Evidence

• src/runtime/node.ts uses timeoutMs directly and Math.max(1000, timeoutMs * 2).
• src/runtime/optimized-node.ts uses timeoutMs directly in setTimeout.
• Tests in test/runtime_config.test.ts allow invalid timeouts but code does not sanitize.

Proposed fix

• Validate timeoutMs on construction: if not finite or < 0, fall back to default (30s) or clamp to 0.
• Ensure TimedOutRequestTracker is constructed with a finite TTL.

Acceptance criteria

• Invalid timeoutMs does not lead to NaN TTL or immediate unexpected timeouts.
• Add tests that pass NaN/negative values and assert sanitized behavior.

[bbopen]

Resolved by PR #150. validators.ts provides assertPositive() and assertFiniteNumber() to validate timeoutMs. BoundedContext exposes these via validatePositive()/validateNumeric().