v0.5.1

A bug fix. One unreachable channel no longer silences upgrade announcements
for every other channel.

One dead channel no longer silences the announcement (#89)

The poster behind upgrade announcements (#77) was an unguarded loop over the
configured channels, so the first chat_postMessage to raise aborted the rest.

Found the hard way while cutting v0.5.0 on a live instance: one configured
channel held a stale IM id that Slack no longer resolves, it happened to sort
first out of the set, and the v0.5.0 announcement reached none of the four
healthy channels. The only trace was a single channel_not_found traceback
about a single channel -- nothing said that four other channels had been
skipped.

Now each channel is posted independently and a failure is logged by channel
name, so the gap is visible instead of silent:

announce: could not post to gregory-dm

The other half is when to report failure upward. announce deliberately does
not record a post that failed, so it retries on the next boot -- correct for a
total failure, wrong for a partial one, which would re-announce to the channels
that already have it on every boot. With KeepAlive plus the #66 watchdog,
boots are frequent. So the poster now raises only when no channel accepted the
message.

Worth stating plainly, because it is why this was silence rather than spam: set
iteration order is stable for a given set of ids. The dead channel sorting first
is the only reason nothing was posted at all. Change the channel list and the
same defect posts to the healthy channels, dies on the dead one, records
nothing, and repeats every boot.

Fan-out semantics stay in the poster rather than moving into announce, which
owns the version comparison and the state file and knows only post(text) --
see CLAUDE.md.

Upgrading

git pull
.venv/bin/pip install -r requirements.txt
.venv/bin/python selfcheck.py
deploy/service.sh restart

• Nothing to change. No new config key, no new dependency.
• Worth checking once: if an announcement ever failed to arrive somewhere,
  a stale channel id may be sitting in your shmobster-config.json. Every
  channels entry should resolve via conversations.info, and the bot has to
  be a member of each private one. A DM entry whose id no longer resolves can be
  re-resolved with conversations.open for that user.