fix: channel editors silently dropping unknown fields on save

[naiqus]

Problem

All four channel form editors in OpenClawConfigCenterPage.tsx (telegram, dingtalk-connector, slack, feishu) silently drop fields on Save.

User flow that loses data:

1. Open a channel resource in the JSON tab, add any field not owned by the form (e.g. webhook, custom capabilities, additional feishu accounts).
2. Switch to the Form tab and change anything (e.g. rotate a secret).
3. Click Save.
4. Reload the page. The field from step 1 is gone from the saved config.

Root cause — two lossy layers

Both the frontend editor and the backend storage normalizer rebuild each config from a hard-coded field allowlist instead of merging the patch onto the existing parsed config. Fixing only one of them is not enough to survive a reload.

Frontend: update*ChannelContentText in OpenClawConfigCenterPage.tsx

const existingConfig = parsed;
const config = {
  enabled: true,
  botToken: nextForm.botToken,
  dmPolicy: existingConfig.dmPolicy || "open",
  allowFrom: readStringArray(existingConfig.allowFrom) || ["*"],
};

Every key not in that literal is silently deleted. Feishu is the worst case — it collapses accounts to just { main: {...} }.

Backend: normalizeOpenClawResourceContent in openclaw_config_service.go

Called on every create/update; delegates to normalize{Telegram,Slack,DingTalk,Feishu}ChannelConfigForEnv. Those helpers serve double duty — they are correct for rendering the runtime env payload (appendCompiledOpenClawEnvPayload re-runs them at render time), but when applied verbatim as the storage normalizer they strip tenant-authored keys before persisting.

Concrete loss matrix (pre-fix)

Editor	Preserved	Silently dropped
telegram	enabled, botToken, dmPolicy, allowFrom	webhook, custom capabilities, any custom keys
dingtalk-connector	enabled, clientId, clientSecret, allowFrom	dmPolicy, webhook, custom keys
slack	enabled, botToken, appToken, groupPolicy, channels, capabilities	allowFrom, dmPolicy, custom keys
feishu	enabled, accounts.main only	every account other than main; every sibling field on accounts.main (e.g. verificationToken); every other top-level field

Fix

Frontend — spread existingConfig first, then override only form-owned keys so later literal keys win. Fallbacks (|| "open", || ["*"]) still evaluate against existingConfig. For feishu also deep-merge the accounts map and accounts.main so sibling accounts and sibling fields both survive.

Backend — introduce mergeOpenClawChannelConfigForStorage, which overlays the allowlist-normalized output onto the original parsed payload at storage time. Normalized keys still win; unknown keys pass through. For feishu the accounts map is merged member-wise.

Env-rendering semantics are unchanged: appendCompiledOpenClawEnvPayload continues to call the *ForEnv helpers at render time against the stored content, so the runtime env payload sees the same allowlist as before. Only storage is now a superset.

Diff

 backend/internal/services/openclaw_config_service.go      | 60 +++++++++-
 backend/internal/services/openclaw_config_service_test.go | 131 +++++++++++++---
 frontend/src/pages/openclaw/OpenClawConfigCenterPage.tsx  |  10 +
 3 files changed, 198 insertions(+), 3 deletions(-)

Verification

Backend tests

Two existing tests (TestResourcePayloadFromModelNormalizesStored{Channel,DingTalkChannel}JSON) asserted the pre-fix behavior (dropping legacyField); updated to assert it survives.

New regression guards:

• TestNormalizeOpenClawResourceContentPreservesUnknownChannelFields — table-driven across telegram / dingtalk-connector / slack, asserts webhook, dmPolicy, allowFrom, custom capabilities all survive write-time normalization.
• TestNormalizeOpenClawResourceContentPreservesFeishuSiblingAccounts — asserts deep-merge of feishu accounts: default and acme survive untouched; main.verificationToken survives; main.appId / main.appSecret are still normalized.

The existing render-path test (TestRenderCompiledOpenClawPayloadRendersChannelsAsKeyedConfigMap) continues to pass unchanged, proving the env-render allowlist is not affected.

[Iamlovingit]

@naiqus Hi, this PR has conflicts. Could you please help resolve them? Thanks!

[naiqus]

Sure. It has been resolved now.

[Iamlovingit]

/lgtm

[Iamlovingit]

@naiqus Thanks your contributions!