Set KIMAKI_NO_DEFAULT_CHANNEL on managed Kimaki services

[chubes4]

Kimaki recreates a general-purpose #kimaki-<bot> channel, welcome message, and tutorial thread on every start. On a wp-coding-agents install the real project channel is the site channel, so the default is pure noise — it has been reappearing on every restart of every managed install since setup.

remorses/kimaki@7a9ab1e8 added KIMAKI_NO_DEFAULT_CHANNEL=1 as the supported opt-out (fixes remorses/kimaki#175). This sets it.

Three render sites, not one

site	function
fresh systemd unit	_kimaki_install_systemd → ENV_BLOCK
upgrade-time merge into an installed unit	bridge_update_systemd → TEMPLATE_ENV
launchd plist	bridge_render_launchd

The middle one is the one that matters most and the easiest to miss. Every host that already exists got its unit written before the opt-out was available, so an implementation that only touches the fresh-install path would fix nothing on any box currently running.

Inert today, correct tomorrow

7a9ab1e8 lands after release: kimaki@0.23.1 and still carries an unconsumed changeset, so the variable is not in any published Kimaki. An unknown env var is ignored, so this is a no-op on current builds and self-activates the moment a host upgrades.

That is deliberate. The alternative I started with was a polling script that hunted the channel down and deleted it after startup — more moving parts, racy, and obsolete the day upstream shipped the flag. A declarative Environment= line has no runtime behavior to go wrong.

Test

tests/bridge-render.sh snapshots only reach the launchd plist: bridge_render_systemd takes its env block as an argument rather than building it, so neither systemd path is snapshot-covered. That gap is why the new test exists.

tests/kimaki-no-default-channel.sh drives the real bridge_update_systemd against a unit written the way a pre-opt-out host has it, and asserts:

• the variable is merged in, exactly once
• an operator-owned Environment=HOST_CUSTOM= line survives the merge
• a second run does not duplicate it (the merge reports unchanged)
• the launchd plist declares the key and sets it to 1
• both systemd env blocks declare it — so a future fourth render site or a dropped one is caught

Verified non-vacuous: reverting just the TEMPLATE_ENV line makes the suite exit 1.

The kimaki-launchd snapshot is refreshed for the new key. bridge-render, kimaki-multi-instance, kimaki-launchd-start, service-identity-adoption, and posture all still pass; bash -n clean across the repo.

Follow-up

Applying this to h44lacrosse.com is an operator action and is not part of this PR. It will not silence that box until Kimaki ships a release containing 7a9ab1e8.