Let the clients edit a Slack channel's behavior options

[edwin-zvs]

Follow-up to #1166 and #1168.

Those two PRs added three options to a Slack channel definition — progress
(what the thread shows while a turn runs), follow_up (whether the bot answers
untagged messages), and thread_context (how much of a thread it reads on
joining) — and neither gave any client a way to set them. The only way to change
one was to hand-edit <config>/services/<name>.toml and wait for the watcher.

The gap was explicit in the code: put_channel carried the three forward under a
"Not editable through this path yet" comment, with a test pinning that workaround
in place, and channel_summary never returned them — so a client could not even
display the value it was about to preserve.

What changed

Protocol. ServiceChannelSummary and ServiceChannelPut each gain
progress, follow_up, and thread_context as Option, so an omitted option
still means "keep the stored value" — the preserve-on-absent behavior every
client relies on today is unchanged. The canonical value lists and the thread
context ceiling live here, so both clients and the daemon's validator cycle and
check against one ordering. Three new ServiceFields declare
PropagationClass::Immediate, matching the supervisor, which already replaces a
Slack task whose config differs.

Daemon. channel_summary reports the three for Slack channels only.
put_channel takes supplied → existing → default. An unknown value, a thread
context past Slack's ceiling, and any of the three on an HTTP channel are
rejected rather than silently defaulted.

TUI. The Slack channel editor grows three rows before State: Progress and
Follow-up cycle with Space/→ forward and ← back, Thread context takes a typed
number clamped to the cap. HTTP channels are untouched.

Web client. The same three, as two selects and a number input.

Specs. 0173 names the behavior options in its "applies immediately" row.
New 0180 records the rule this gap breaks — an option that exists in a channel
definition has to be reachable from the clients that edit channels. Two
consecutive PRs introduced the same gap, which is what makes it worth writing
down rather than just fixing.

Tests

Daemon: an omitted option preserves the stored value; a put sets all three;
unknown values, an over-cap thread context, and the options on an HTTP channel
are each rejected; the published defaults match what a definition gets.
TUI: the editor renders the three rows, Space/arrows cycle through the canonical
order and wrap, and a typed thread context clamps.

cargo test --workspace is green.

Binaries

Spans crates/protocol, crates/daemon, crates/cli → the binary to run is
construct:

/Users/moon/agentd/.claude/worktrees/slack-channel-options/target/debug/construct

[edwin-zvs]

The Slack channel editor, with the three new rows (Progress selected, so the help column explains it):

Recorded from the branch with an isolated daemon under /tmp. Progress and Follow-up cycle in place; Thread context renders 0 as none and anything else as a message count.