Greptile Summary

This PR fixes a crash in resolveTelegramToken (and therefore openclaw doctor --fix) when a botToken is configured as an unresolved SecretRef object (e.g. a file-based secret provider). The old normalizeResolvedSecretInputString helper throws on any unresolved ref, while the gateway runtime can resolve these refs fine at runtime.

Changes:

• extensions/telegram/src/token.ts — swaps normalizeResolvedSecretInputString for normalizeSecretInputString + hasConfiguredSecretInput at both the account-level and top-level botToken resolution points. An unresolved SecretRef now yields { token: "", source: "config" } instead of throwing.
• extensions/telegram/src/token.test.ts — updates the existing throw-expectation test and adds a new case for an account-scoped file SecretRef.

The fix is consistent with the existing pattern used in account-inspect.ts and correctly passes cfg?.secrets?.defaults so that legacy refs without an explicit provider are still coerced properly. No issues found.

Confidence Score: 5/5

• This PR is safe to merge — the change is targeted, well-tested, and consistent with established patterns in the codebase.
• The fix is minimal and surgical: two call-site swaps in token.ts, matching the existing pattern from account-inspect.ts. The helper functions (normalizeSecretInputString, hasConfiguredSecretInput, coerceSecretRef) are well-understood with no side effects. All 14 token tests pass, the type signatures align correctly, and the fallback precedence (account token → top-level token → env) is preserved unchanged for every case except the previously-crashing unresolved SecretRef path.
• No files require special attention.

_{Last reviewed commit: 16b88d9}

Thanks for the contribution and for targeting the Telegram unresolved-SecretRef failure path. We merged #48728 as the cluster-wide fix, and it includes this doctor/Telegram robustness surface plus related status/message isolation changes in one unified path. Closing this PR as superseded by #48728.