feat(bots): Mattermost payload compatibility + 100% coverage of the bot platform

[habibaltaf]

Mattermost payload compatibility + 100% coverage of the bot platform

Answers "is the bot API compatible with Mattermost?" — it now is, at the payload
level, for the three integration surfaces third-party bots actually use. Also
brings the whole bot platform to the repo's 100% statement gate, including the
parts that predated this branch and had no tests at all.

Design record: docs/rfc-generic-bots-mcp.md (§2 rewritten, §8a added, D4/D5).

What an existing Mattermost integration can now do against ex

Surface	Before	Now
Incoming webhooks	✅ already compatible	unchanged
Outgoing webhooks	ex-only signed JSON	✅ MM form-encoded (opt-in per bot)
Trigger words	❌ none	✅ trigger_word + trigger_when
Slash commands	❌ none	✅ MM request/response + response_url
Interactive actions	❌ none	✅ buttons/selects + callback

• Outgoing webhooks — per-bot transport. "mattermost" sends MM's
  form-encoded fields with the shared secret as the body token. "ex" (the
  default for new bots) keeps HMAC-signed JSON, which is strictly better
  authentication — a signature bound to a timestamp rather than a bearer token
  in the body. Opt in per bot, so an existing MM bot works unchanged without
  weakening anything new.
• Slash commands — admin-registered trigger + request URL, MM's invocation
  and response shape (response_type, text, attachments, goto_location),
  and a working response_url for delayed replies (30-min TTL, matching MM).
• Interactive actions — MM's attachment actions with
  integration.{url,context}, its action request and update /
  ephemeral_text response.
• Admin APIs are snake_case and accept MM's spellings (username,
  display_name, trigger_word).

Still not a drop-in MM server. ex serves /api/v1, so mattermost-driver,
mmpy_bot and MM plugins do not work against it — that stays a non-goal (D1).
Reaching it would need a real unique username on model.User (a data
migration; ex has only email + display name), a synthetic team threaded through
every team-scoped route, an id format MM clients accept (bot_<ulid> is 30
chars where MM validates 26 lowercase alphanumerics), and a
/api/v4/websocket speaking MM's frame protocol.

Two documented approximations, centralized in service/mmcompat.go:
team_id/team_domain are a single synthetic team (ex has no teams), and
user_name is derived from the email local part (ex has no usernames) — a
display label, never an identifier. Receivers must key on user_id.

Security-relevant decisions worth a reviewer's attention

• An action's callback URL and context never reach a client. The client
  sends only an action id; ex resolves the stored integration server-side. That
  keeps integration-internal config off the wire and stops a client forging a
  call with a context of its choosing. Implemented as an asymmetric
  MessageAction — inbound JSON populates integration, json:"-" means it is
  never emitted. Pinned by a test.
• Every integration URL goes through the same SSRF boundary as unfurling
  (public https only, re-checked at dial time to defeat DNS rebinding), both
  when persisting an action and when invoking it. An update's actions are
  re-validated, so an unsafe URL can't be smuggled in via a callback response.
• MM defaults an unset command response_type to ephemeral. ex matches
  that, so a command answering with bare text does not publish to the channel.
  Getting this backwards would leak output integrations expect to stay private.
• A retired bot fails closed. DeleteBot now clears its callback URL and
  triggers, so an @mention or trigger word can no longer reach a deactivated
  bot's endpoint.
• response_url is unauthenticated by design (MM's contract). Everything it
  may do — which chat, as whom — is pinned server-side at mint time and
  re-access-checked before posting, so a stolen token can only do what the
  original invocation could, and only until the TTL.

Coverage: 100%

Total coverage threshold (100%) satisfied:  PASS
Total test coverage: 100% (13088/13088)

Files that had no coverage before this PR: store/bot.go and
store/redis_cliffy_inchat.go (0%), handler/bot.go and
handler/cliffy_inchat.go (4%), service/botdispatch.go's async half (42%),
handler/cliffy.go (54%).

Three seams added so untestable behaviour became reachable — each narrowing a
real bug class, not just moving a number:

• handler.cliffyPendingStore — makes the confirm-first race (two "yes" replies
  where only one may execute a cross-app write) deterministic instead of
  timing-dependent.
• handler.MessageActionInvoker, service.CommandResponseStore — test the HTTP
  contract and the response_url path without the message service / Redis.

Per COVERAGE.md, provably-dead guards were deleted rather than annotated:
three json.Marshal-over-strings sites, HMAC signing with a []byte key (now
service.mustSigned, with a panic test), re-marshalling a value that just came
from Unmarshal (now handler.mustJSON), and a duplicated not-configured
branch in ProxyAPI its own fail-fast guard already covers. CreateCommand
moved onto the existing randRead seam so its randomness-failure arm stays
reachable.

Bugs found and fixed along the way

A typed-nil trap (introduced by the interface seam, then fixed): assigning a
nil *store.CliffyInChatStore to an interface field yields a non-nil
interface holding a nil pointer, so every h.inchat != nil guard passed and
then dereferenced. NewCliffyHandler now assigns only when non-nil, with a
regression test.

Silent bot-admin failures: delete and revoke surfaced nothing on failure,
which reads as a dead button. They now show the server's reason, and a 404 hints
that the API build may be stale.

Pre-existing failures this PR does not fix

Both trace to 8166236 ("Cliffy in-chat UI + draggable/dismissable launcher")
and fail deterministically, independent of this work:

1. conversation-view.browser.test.tsx > sends a new conversation message —
   the draggable Cliffy launcher (fixed bottom-24 right-5 z-40) has a Lottie
   <path> that intercepts clicks on the composer's Send button. This is a
   real UI bug, not just a test failure: users can't click Send where the
   launcher overlaps. The fix is a design call (pointer-events-none on the
   animation layer, or reposition), so it's left for the owner.
2. AuthContext.browser.test.tsx > logout POSTs to /auth/logout — that
   commit added revoke-on-logout, so logout now POSTs /api/v1/cliffy/revoke
   before /auth/logout (deliberately, while the token is still valid). The
   test still asserts the first fetch is /auth/logout and was never updated.
   The code is right; the test is stale.

Verification

• go build, go vet (both tag sets), gofmt, make check-types-drift — clean
• Full Go suite with -tags=integration against DynamoDB Local + Redis — 17/17
  packages pass
• Backend coverage gate — PASS at 100%
• tsc -b, eslint src/ — clean
• Frontend suite: the jsdom project passes. The merged jsdom+browser coverage
  number is not verified here — Playwright's chromium/webkit were not
  installed locally, so every .browser.test.tsx had been contributing zero
  coverage; after installing them the suite could only be run on a machine at
  load 59, where 147 of 152 failures were Error: Test timed out. The same
  files pass in isolation (Sidebar.test.tsx 73/73,
  MessageItem.branches.browser.test.tsx 108/108 in 28s). This needs CI or an
  idle machine to confirm.