feat: respect configured output verbosity; quiet medium by default

[kevin-david]

Why

The verbosity mode setting was effectively dead before — the discord adapter's sendMessage override called super.sendMessage(), which resolves verbosity via the base class's channel-config lookup. That lookup doesn't see the discord plugin's settings-backed outputMode and silently fell back to medium. As a result, neither low nor high had any runtime effect.

What changes

Routing fix — sendMessage now dispatches via this.resolveMode(sessionId), which reads the discord plugin settings (and per-session override).

Medium becomes quieter — usage embeds and the cross-channel Task-completed ping were firing at every prompt's end. Most users find that noisy at the default tier. They're now gated to high only — opt-in via explicit verbosity for users who want the metrics.

Mode	Thinking text	Tool cards	Usage embed	Task-completed
low	hidden*	compact*	hidden	hidden
medium	shown	full	hidden (NEW)	hidden (NEW)
high	shown	full + extra	shown	shown

* Low has a pre-existing draft-finalization bug (text never finalizes because handleUsage isn't called when usage events are filtered upstream by HIDDEN_ON_LOW). Out of scope for this PR — happy to address separately if anyone wants low to be a viable tier.

Test plan

• Verified by running from source locally
• Reviewer: set outputMode: "high" → confirm usage embed and Task-completed fire at end of each prompt
• Reviewer: set outputMode: "medium" → confirm thinking text + tool cards still render but no usage embed / Task-completed

🤖 Generated with Claude Code

[kevin-david]

There's still some weirdness here, at least with gemini - prior messages being edited. Marking as draft for now

[kevin-david]

Tuns out that was a different issue and this should be fine! More PRs coming...

[0xmrpeter]

Thanks for tracking this down! The routing change from getVerbosity() to resolveMode() is exactly right — the plugin's output mode settings were being completely bypassed before this fix.

A couple of minor notes for follow-up:

• Double resolveMode call in handleUsage — the method now correctly receives verbosity as a parameter, but still calls this.resolveMode(sessionId) internally. The two values are always equal, so it's worth consolidating to use the passed-in param.
• Inconsistency across handlers — handleUsage is now the only handler that actually uses its verbosity param; the others (handleThought, handleToolCall, etc.) still use the _verbosity underscore pattern and resolve internally. Making this consistent across all handlers in a follow-up would remove the asymmetry.
• Test coverage — a unit test covering the medium vs. high verbosity gate in handleUsage would make this much more solid, since this is a silent behavior change for existing deployments.

Overall a clean and necessary fix.