Add thread follow/unfollow via Mattermost threads API #42

(Written entirely by claude code opus 5 high and slightly revised by me.)

Collapsed reply threads carry a per-user follow state that matterbox never reads or writes, so a thread can be neither followed from the TUI nor used as a rule condition. On a server with CollapsedThreads: always_on — the default on current Mattermost — that state is what the official clients notify on, and unfollowing is the only per-thread mute a user has.

The endpoints are already reachable through the vendored client:

• GET /users/me/teams/{team}/threads/{root} — 200 with the membership when followed, 404 app.user.get_thread_membership_for_user.not_found when not.
• PUT / DELETE …/threads/{root}/following — follow / unfollow.
• GET /users/me/teams/{team}/threads — the followed set, carrying unread_replies and unread_mentions per thread, plus a totalsOnly=true form.

Proposed surface:

• mm.Client: GetUserThread / GetUserThreads / UpdateThreadFollowForUser wrappers.
• TUI: follow_thread and unfollow_thread keybinding actions, and a followed marker in the thread pane. matterbox keys lists 84 actions today and none of them touches follow state, so a thread opened with open_thread cannot be muted without leaving the terminal.
• CLI: matterbox thread follow|unfollow|status <root-id>
• rules: a following: true|false condition in match:. This is the one that matters most for listen: is_thread alone cannot express "a reply in a thread I follow", which is exactly the criterion the Mattermost clients notify on.

For what it's worth, I bridged this from outside to get desktop notifications for followed threads: a listen exec rule whose script reads the follow state over the API before notifying, plus a shell wrapper for follow/unfollow. It works — about 85 ms per membership lookup, and a DM thread resolves against any team the user belongs to, since a DM carries none — but it re-implements in shell what the rules engine and the TUI are the right home for.