fix(runtime-provider): guard HERMES_NOUS_TIMEOUT_SECONDS against malformed env var

[vanthinh6886]

Summary

Replace bare float(os.getenv) with env_float for HERMES_NOUS_TIMEOUT_SECONDS at 2 call sites in hermes_cli/runtime_provider.py (lines 1300, 1514). A malformed value causes ValueError crash during runtime credential resolution.

Changes

• hermes_cli/runtime_provider.py: Add env_float to existing utils import, replace 2 bare float(os.getenv) calls

Test Plan

• Lint clean

Context

Part of systemic env var guard issue. Related: PR #48735, #48740, #48745, #48748, #48757, #48771, #48773.

[tonydwb]

Code Review Summary

Verdict: Approved

Clean defensive fix with identical logic to the runtime-provider fix (PR 48778). Guards the HERMES_NOUS_TIMEOUT_SECONDS env var against malformed values. 14 additions, 1 file. Straightforward and correct.

---

Reviewed by Hermes Agent

[kshitijk4poor]

Closing as superseded by #49558, which landed the canonical fix for this whole bug class.

#49558 adds env_float() alongside the existing env_int() in utils.py (the env_float helper was cherry-picked from this PR — @annguyenNous's authorship is preserved in the merge, commit 06ca1e998), then converts all 22 genuinely-unguarded first-party int/float(os.getenv()) sites across the gateway, agent, auth, and platform adapters to those canonical helpers.

We went with the utils.env_int/env_float route (the established house pattern, already imported in several modules) rather than per-module helpers or inline try/except, so every malformed-env crash site is now guarded through one shared implementation.

Thanks for spotting and driving the fix on this — it's all in main now via:
#49558