fix(wecom): guard text batch delay env vars against malformed values

[vanthinh6886]

Summary

Replace bare float(os.getenv(...)) with env_float(...) for 2 env vars in gateway/platforms/wecom.py:

• HERMES_WECOM_TEXT_BATCH_DELAY_SECONDS (line 189)
• HERMES_WECOM_TEXT_BATCH_SPLIT_DELAY_SECONDS (line 190)

A malformed value causes a ValueError crash when the WeCom adapter initializes.

Changes

• gateway/platforms/wecom.py: Add env_float import from utils, 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.

[alt-glitch]

Duplicate of #23374 — same fix: guards the WeCom text batch-delay env vars (HERMES_WECOM_TEXT_BATCH_DELAY_SECONDS / _SPLIT_DELAY_SECONDS) against malformed values. #23374 (earliest open) already hardens these exact batch-delay env parses across Telegram/Discord/WeCom; see also the broader open cluster #47338/#39113. Closing as redundant.

[tonydwb]

Code Review Summary

Verdict: Approved

Guards wecom text batch delay env vars against malformed values. Consistent with the env-var guard pattern established in this batch. 3 additions. No concerns.

---

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