When no accountId was provided, resolveTelegramAccount and resolveTelegramToken
resolved the implicit default account first. Any leftover TELEGRAM_BOT_TOKEN or
top-level channels.telegram.botToken then shadowed the configured
channels.telegram.defaultAccount and default-agent binding, so gateway sends,
heartbeats, and message actions went out through the wrong bot and typically
failed with chat not found in groups the stale bot never joined. Message
actions could also fail with a missing-token error when only the named default
account had a token.
Resolve the configured default account id up front in both optional-account
entry points, matching the nextcloud-talk resolver and createTelegramActionGate.
Keep the top-level Telegram default account in the account list when named accounts or bindings are added alongside top-level credentials. This preserves default polling while still allowing named-only configs to resolve to their single configured account.
`mergeTelegramAccountConfig` and the generic `resolveChannelGroups` both used
`accountGroups ?? channelConfig.groups` to fall back to root group allowlists,
which only catches the `undefined` case. An explicit empty `{}` survives
nullish coalescing and overrides the root allowlist with an empty allowlist,
which then pairs with the default `groupPolicy: "allowlist"` to silently
deny every group update — the symptom reported in #79427.
Treat an explicit empty `{}` the same as undefined for fallback purposes in
single-account setups (one or zero configured accounts). Multi-account setups
keep current semantics so per-account explicit-empty groups still scope
disable a single account without affecting its siblings. The explicit way to
block all groups for any account remains `groupPolicy: "disabled"`, which
this PR does not touch.
Fixes#79427.
