[Feature]: gate Feishu active confirmations on conversation readiness and send failure alerts when model config is broken

[zhyongrui]

Summary

Change Feishu proactive confirmations so they only report success after OpenClaw has passed a real conversation-readiness check. If the selected provider/model/API config is broken, send a failure alert instead of a success message.

Problem to solve

Current startup confirmation behavior can send a proactive Feishu message even when OpenClaw cannot actually answer chat requests.

As of the current implementation on April 16, 2026, the confirmation is sent when the runtime is up and a Feishu operator target exists, but it is not gated on model/provider/API readiness. This means operators can receive a message that implies OpenClaw is active even though the configured provider or API settings are wrong and real conversations will fail.

That is misleading for the main operator use case. The purpose of the proactive message should be to confirm that OpenClaw is ready for normal conversation, not merely that the process started.

Proposed solution

Replace the current success condition with a conversation-readiness gate.

Desired behavior:

1. On startup or setup completion, run a readiness probe for the selected conversation model/provider.
2. Only send the success confirmation after that probe passes.
3. If the probe fails, proactively send a failure warning instead of a success message.

Success meaning:

• the selected provider/model resolves correctly
• auth is valid
• the upstream API is reachable
• OpenClaw can complete a minimal real conversation/request path successfully

Recommended success message:

• OpenClaw 已启动，并已通过对话可用性检查。
• 当前配置已生效，现在可以正常对话。

Recommended failure warning:

• OpenClaw 已启动，但当前模型配置不可用，请检查 provider/API 设置。

Alternatives considered

• Keep sending a startup success message whenever the process starts.
  This is simple but inaccurate and can mislead operators.
• Send no proactive message at all.
  This avoids false positives but removes useful operator feedback.
• Send a weaker liveness-only message.
  Better than a false success signal, but still weaker than directly confirming conversation readiness.

Impact

Affected:

• Feishu operators using proactive startup/setup confirmations
• setups where provider, model, API key, or base URL are misconfigured
• repeated configuration testing on the same machine

Severity:

• High for operator trust and setup UX

Frequency:

• Any time startup succeeds at the process/channel level but model readiness is broken

Consequence:

• Operators believe the assistant is usable when it is not
• wasted time debugging after a misleading success notification
• reduced trust in proactive status messages

Evidence/examples

Observed locally on April 16, 2026:

• OpenClaw/OpenClawCode could proactively message Feishu even when the provider/API configuration was intentionally wrong
• the operator intent was to use the proactive message as proof that normal conversation was working
• current startup confirmation logic in extensions/openclawcode/index.ts sends a success message without provider/model/API readiness validation

Relevant behavior area:

• extensions/openclawcode/index.ts
• startup confirmation path added by fix(issue-152): always confirm feishu setup and startup

Additional information

This is a semantics issue, not just a copy issue.

If the product wants the proactive message to mean "OpenClaw is ready to talk", the runtime must verify real conversation readiness before sending it.

If readiness fails, the product should proactively warn the operator with:

• OpenClaw 已启动，但当前模型配置不可用，请检查 provider/API 设置。