fix(web): show the full path in file link tooltips - #7741

💭 Let me look at the code surrounding this change.

1. browse_code — apps/web/src/components/ChatMarkdown.tsx

💭 I'm checking whether displayPath is still used elsewhere since the tooltip now shows targetPath instead—confirming it's still referenced for the "Copy relative path" context menu item, so nothing becomes unused. I also want to verify whether targetPath might include a line number suffix that shouldn't appear in the tooltip.

2. git_tools — targetPath|displayPath|workspaceRelativePath

💭 I'm wondering whether there's an existing test that checks the tooltip displays the displayPath rather than the full targetPath, so I should search for references to the tooltip content in the ChatMarkdown tests.

3. git_tools — MarkdownFileLink|MARKDOWN_FILE_LINK_CLASS_NAME

💭 There's no component test here, just a small content change where the tooltip now shows the full path instead of a shortened one. I want to check whether other file chip tooltips elsewhere in the codebase show workspace-relative paths, since that would affect whether this change is consistent with existing UI patterns.

4. git_tools — FileTagChipContent|CHAT_FILE_TAG_CHIP_CLASS_NAME

💭 Let me check the git history of that tooltip line to see if the displayPath was intentional, maybe there's a comment or a prior commit that deliberately changed it from targetPath to displayPath.

5. git_tools

💭 I don't see a functional issue beyond the tooltip being the only place showing the full path, and the scrollbar styling override is pre-existing rather than newly introduced. I'm checking whether targetPath already includes the line/column suffix, since tests show it resolved with something like ":71" appended. Both displayPath and targetPath include the line number, so that's consistent, and the tooltip being a longer absolute string is fine given the scrollable, max-width container. I also confirm resolveMarkdownFileLinkTarget properly decodes file:// URLs, so edge cases like Windows paths or URL-encoded paths are handled. Overall this looks clean with no real findings, so I'm leaning toward reporting "all clear."