fix(channels): prevent legacy flat config from blocking new account creation

[octo-patch]

Fixes #831

Problem

When a channel (e.g. DingTalk) is stored in the legacy flat format — a config section without an explicit accounts object — getChannelConfig() falls back to returning the entire top-level channel section for any requested accountId.

This interacts badly with the isSameConfigValues() guard in POST /api/channels/config: when a user clicks Add Account and enters the same credentials as the existing channel, getChannelFormValues() returns the existing flat config as if it belonged to the brand-new UUID-based accountId (e.g. dingtalk-abc12345). isSameConfigValues() then reports "no change" and returns { success: true, noChange: true } — silently skipping the save.

From the user's perspective, clicking "Add Account → Submit" appears to succeed (no error) but no new account appears in the list, giving the impression the existing account was edited in-place.

This regression was introduced when the isSameConfigValues early-return was added in #496 (after the accounts-based storage refactor in #420) and affects any user whose channel config predates the accounts migration.

Solution

Guard the backward-compat fallback in getChannelConfig() so it only applies when no specific accountId is requested, or when the default ('default') accountId is requested. When the caller supplies a newly-generated account ID that does not exist in the config, undefined is returned — the correct "not found" signal — allowing the save to proceed and the new account to be created.

// Before
if (!accounts || Object.keys(accounts).length === 0) {
    return channelSection;
}

// After
if ((!accounts || Object.keys(accounts).length === 0) && (!accountId || resolvedAccountId === DEFAULT_ACCOUNT_ID)) {
    return channelSection;
}

Testing

• Configure a channel (e.g. DingTalk) that was saved in legacy flat format
• Click "Add Account" and enter credentials identical to the existing account
• Verify the save proceeds (new account appears in the list) rather than being silently swallowed
• Verify that fetching config for the default/unspecified account still falls back correctly to the flat legacy format

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1b9708d675

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Keep systemd conflict line visible in production logs

Downgrading already running under systemd to debug hides the only specific root-cause signal in packaged builds, because the logger defaults to INFO there and debug messages are suppressed. In the failure path, startup still surfaces a generic error (Gateway process exited before becoming ready), so this change makes real systemd conflicts much harder to diagnose from user logs/support bundles even though the app now fails fast.

Useful? React with 👍 / 👎.