feat(message-service): add getPathThrough for branch-aware path queries

[DeJeune]

What this PR does

Before this PR:

Branch-aware navigation in the chat tree had no read-only way to compute "the path through this sibling". The previous workaround was a descend mode on setActiveNode, which both resolved the path AND persisted it to topic.activeNodeId — unsuitable for hover/preview UI.

After this PR:

MessageService.getPathThrough(topicId, nodeId) returns the conversation path passing through nodeId, descending into its subtree to the leaf with the greatest created_at (skipping deleted nodes). If nodeId has no live children, the leaf is nodeId itself. Pure read — does not touch topic.activeNodeId. Callers that want to persist the result follow up with setActiveNode on the returned leaf.

Exposed as GET /topics/:topicId/path?nodeId=X via DataApi.

Fixes #

Why we need it and why it was done in this way

The following tradeoffs were made:

• Implemented as a recursive CTE rather than iterative TS traversal — keeps subtree walk + leaf selection in one round-trip, avoids N+1 fetches for deep trees.
• Returns NOT_FOUND (rather than empty path) when nodeId is unknown or belongs to a different topic — surfaces caller bugs early instead of silently returning [].

The following alternatives were considered:

• Re-purposing setActiveNode with a non-persisting flag — rejected; mixing read and write semantics on the same method was the original confusion.

Links to places where the discussion took place: N/A

Breaking changes

None.

Special notes for your reviewer

This commit was cherry-picked out of DeJeune/ai-service so the getPathThrough API can land on v2 independently of the larger AI service work. The receiving callers (SiblingNavigator / MessageGroup wiring) remain on DeJeune/ai-service and will rebase once this lands.

The conflict during cherry-pick was a co-located reserveAssistantTurn test from a different commit on the source branch — dropped from this PR. Also adapted the test seed to origin/v2's topic schema (no orderKey column on v2).

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

NONE

[0xfullex]

Note

This comment was translated by Claude.

What the current code does: starting from nodeId, it traverses upward to find the root, and downward to find the latest child node until reaching a leaf node, forming a single path to return. The code implementation itself is largely fine.

However, the actual product requirements and interactions for such a path are extremely unclear (I cannot think of any use scenario for it).

Therefore, the source of actual requirements and use scenarios need to be clarified first before we can determine whether the code implementation is correct.

---

Original Content

当前代码做的事情：从nodeId向上找到root，从nodeId向下寻最新子节点一直到叶子节点，组成单一路径返回。其代码实现本身问题不大。

但是，对于这样的路径，其在产品中实际的需求和交互是什么，是极其不明确的（我想不到其使用场景）。

因此，需要先澄清实际需求来源和使用场景，才能明确代码实现是否正确。