fix(gateway): coerce scalar free_response_channels to str before split

[valda]

Problem

A single-channel Discord/Slack free_response_channels entry configured as a bare numeric YAML value is silently dropped. The bot keeps demanding @mentions even though the channel was configured to free-response, with no log line to point at why.

discord:
  free_response_channels: 1491973769726791812   # bug: ignored
  # free_response_channels: '1491973769726791812'   # workaround: treated as str
  # free_response_channels: 1491973769726791812,9876543210  # coincidentally works — comma forces YAML to parse as str

YAML loads the bare integer as int. _discord_free_response_channels() / _slack_free_response_channels() check isinstance(raw, list) then isinstance(raw, str), and if neither matches fall through to return set(). So any single-channel unquoted numeric ID is silently dropped — which is exactly the footgun that's hardest to diagnose, because the config file "looks right" and the feature just doesn't activate.

A multi-channel value like 1234567890,9876543210 doesn't trip this because the comma forces YAML to parse it as a string. And the old-schema env-var bridge at gateway/config.py:614+ already runs str(frc) when forwarding to SLACK_/DISCORD_FREE_RESPONSE_CHANNELS, so the env-var fallback worked. The bug only surfaces on the config.extra["free_response_channels"] path populated by the platforms: bridge at gateway/config.py:576, which passes the raw YAML value through unchanged.

Fix

Coerce any non-list scalar to str() at the reader before applying the existing CSV split:

if isinstance(raw, list):
    return {str(part).strip() for part in raw if str(part).strip()}
s = str(raw).strip() if raw is not None else ""
if s:
    return {part.strip() for part in s.split(",") if part.strip()}
return set()

This keeps the public contract stable — lists, CSV strings, empty strings, None, and env-var fallbacks all continue to behave identically — while also accepting the int / float scalars that the YAML loader is free to hand us.

Applied symmetrically to both Discord and Slack since they share the exact same pattern.

Tests

Added unit tests covering:

• bare int value in config.extra (the failure case)
• list of int entries in config.extra

for both Discord (test_discord_free_response_channels_bare_int, test_discord_free_response_channels_int_list) and Slack (test_free_response_channels_bare_int, test_free_response_channels_int_list).

Existing test_free_response_channels_list / test_free_response_channels_csv_string / test_free_response_channels_empty_string / test_free_response_channels_env_var_fallback / test_discord_free_response_channel_can_come_from_config_extra still pass unchanged.

tests/gateway/test_discord_free_response.py tests/gateway/test_slack_mention.py
50 passed, 2 warnings in 12.42s

Alternative considered

Coercing at the bridge (gateway/config.py:576) would fix this single field but would leave other platforms:-bridged fields with the same pattern (allow_from, group_allow_from, ignored_channels, …) still vulnerable to a different bare-int YAML footgun. Fixing at the reader is minimal, defensive, and scoped to the two adapters that actually consume this field. If the bridge ever grows a general normalization step that's a strictly bigger change, and this reader-level fix is still correct then.

[kshitijk4poor]

Merged via PR #18553. Your commit was cherry-picked onto current main with your authorship preserved (rebase merge). Thanks for the contribution! 🎉