[Feature]: always send a proactive Feishu confirmation after setup/startup

[zhyongrui]

Summary

Always send a proactive Feishu confirmation message after setup completes and after the gateway/openclawcode starts successfully, even when the operator was already bound before.

Problem to solve

Current Feishu operator binding behavior dedupes the welcome message by accountId + openId. That avoids repeated first-run greetings, but it also means an operator can complete setup successfully and receive no proactive message at all if the same operator had already been welcomed on this machine before.

In practice this is confusing during setup and testing:

• the user picks Feishu/Lark
• chooses Modify settings
• reuses the existing bot
• chooses Work email or Mobile number
• setup finishes successfully
• no proactive message arrives

From the user's perspective this looks like setup may have failed, even though binding succeeded and the target/allowlist state was updated.

Proposed solution

Treat these as two separate concepts:

1. Keep the existing deduped "first welcome" behavior if needed.
2. Independently send a proactive confirmation whenever setup succeeds.
3. Also send a proactive "OpenClaw is active" message whenever the gateway/openclawcode starts successfully.

For the first implementation, keep it simple and noisy rather than silent:

• after successful setup/binding, always proactively message the configured operator target
• after successful startup/restart, always proactively message the configured operator target
• do not suppress these confirmations just because a historical welcome receipt already exists

This gives the operator immediate proof that:

• setup completed
• the current config is active
• openclawcode is alive and connected to Feishu

Example messages:

• OpenClaw setup completed and is now active.
• OpenClaw restarted successfully and is active.

Alternatives considered

• Reuse the existing welcome receipt and send nothing if a receipt already exists.
  This is the current behavior and is too ambiguous for operators.
• Only send the very first welcome message ever.
  This avoids noise but leaves reconfiguration/restart flows with no positive feedback.
• Build a more complex short-lived pending-notification system first.
  This may be the right long-term design, but it is more complex than needed to solve the immediate UX failure.

Impact

Affected:

• Feishu/Lark operators using setup/onboard/reconfigure flows
• local testing and repeated setup on the same machine
• any restart/reload flow where the operator expects confirmation that the service is alive

Severity:

• Medium to high for setup UX

Frequency:

• Common whenever the same operator re-runs setup on an existing machine/state dir

Consequence:

• Operators cannot tell whether setup succeeded
• repeated manual checks (hi, health checks, looking at logs/config) are required
• easy to misdiagnose a successful bind as a setup failure

Evidence/examples

Observed locally on 2026-04-15 UTC:

• the operator binding path via Feishu contact lookup succeeded and updated operator-chat-targets.json
• no proactive message was sent because feishu-operator-welcome-receipts.json already contained a receipt for the same openId
• current code sends the welcome only when hasFeishuOperatorWelcomeReceipt(...) is false
• setup surface text explicitly promises: "After startup, OpenClaw will look up your open_id and send the first welcome message."

Relevant files:

• extensions/feishu/src/setup-surface.ts
• extensions/openclawcode/index.ts
• src/operator-chat-targets/feishu-welcome-receipts.ts

Additional information

This request is intentionally biased toward visibility over noise. A later refinement can distinguish:

• first welcome
• setup success confirmation
• restart success confirmation

But the short-term behavior should favor always telling the operator that OpenClaw is active.