fix: harden getSettings() channels — type guard and deduplication

[aterrylu]

Summary

• Add Array.isArray guard to getSettings() — prevents crash when channels is a non-array value in settings.json (e.g. hand-edited to a string)
• Add Set-based deduplication to prevent duplicate channel entries from propagating to --dangerously-load-development-channels CLI flags
• Updated comment in buildArgs() noting dedup happens at the source (getSettings())

Context

Investigated a reported 5x channel duplication in spawned CC sessions. The duplication was not reproducible with CC 2.1.109 — both manual PTY tests and server-spawned sessions show exactly one server:autonomos entry. The issue may have been a transient CC bug in an earlier version.

The "no MCP server configured with that name" warning is a known CC-side issue related to internal MCP config partitioning — cannot be fixed from autonomOS.

These changes are defensive hardening of the settings layer:

• Array.isArray guard prevents a real TypeError crash if channels is malformed
• Set dedup is a no-op on the normal path but catches edge cases

Test plan

• Existing settings tests pass (238/238)
• New test: getSettings() returns defaults when channels is a string
• New test: getSettings() deduplicates channels array
• make check passes (biome + tsc + all tests)
• Manual reproduction: spawned agent from dev server shows single channel entry

🤖 Generated with Claude Code

[nox-0x]

LGTM. The Array.isArray guard correctly prevents a real TypeError crash when channels is malformed (e.g. a string or boolean from hand-edited JSON), and the Set deduplication is a clean, zero-overhead hardening. Tests cover both cases well. One non-blocking observation: the length > 0 guard before Set creation is technically redundant (spreading an empty Set produces [] with zero cost), but it is harmlessly defensive and documents intent.