feat(broker+api+cli): topic message reply-to threading (v0.3.1)

Adds a reply_to_id column (self-FK on topic_message) plus end-to-end
plumbing so a message can mark itself as a reply to a previous one in
the same topic.

- Schema: 0027_topic_message_reply_to.sql adds reply_to_id with
  ON DELETE SET NULL + index for backlink lookup.
- Broker: appendTopicMessage validates parent shares the topic, writes
  reply_to_id; topicHistory + topic_history_response surface it; WS
  push envelope now carries senderMemberId, senderName, topic name,
  reply_to_id, and message_id so recipients have everything they need
  to reply without a follow-up query.
- REST: POST /v1/messages accepts replyToId (validated server-side);
  GET /messages and SSE /stream emit it per row.
- CLI: \`topic post --reply-to <id|prefix>\` resolves prefixes against
  recent history; \`topic tail\` renders an "↳ in reply to <name>:
  <snippet>" line above replies and shows a copyable #shortid tag on
  every row.
- MCP push pipe: channel attributes now include from_pubkey,
  from_member_id, message_id, topic, reply_to_id — the recipient can
  thread a reply directly from the inbound notification.
- Skill + identity prompt updated to teach Claude how to use the new
  attributes for replies.

Bumped CLI to 1.9.0.

packages/db/migrations/0027_topic_message_reply_to.sql

@@ -0,0 +1,15 @@
+-- Threaded replies on topic messages (v0.3.1).
+--
+-- Adds a self-FK column so any topic message can be marked as a reply to a
+-- previous message in the same topic. ON DELETE SET NULL because deleting
+-- a parent message shouldn't ripple-delete the children — the thread just
+-- becomes "in reply to a deleted message".
+--
+-- Index supports the cheap backlink lookup: "give me all replies to X".
+
+ALTER TABLE "mesh"."topic_message"
+  ADD COLUMN IF NOT EXISTS "reply_to_id" text
+    REFERENCES "mesh"."topic_message"("id") ON DELETE SET NULL ON UPDATE CASCADE;
+
+CREATE INDEX IF NOT EXISTS "topic_message_by_reply_to"
+  ON "mesh"."topic_message" ("reply_to_id");