Inline code chips hide part of relative paths that aren't files

[gkfirst8]

Inline code like `size/provider/file.jpg` renders as a chip labelled file.jpg. In my case it was part of an image URL, not a file in the workspace. The chip drops the first two segments, so the reader can't see what the agent wrote, and clicking it opens a file that doesn't exist.

No text rule can catch this. size/provider/file.jpg has the same shape as src/main.ts, and the current tests treat vendor/jquery-3.6.0.min.js and share/man/ls.1 as files on purpose. Absolute paths have a cheap fix (require a known filesystem root or the workspace, #19012). Relative paths don't.

I can see two ways out:

1. Only make a chip when the file exists. The server can already answer this through projects.searchEntries and projects.listEntries. It costs a round trip per message, though, and the chip would appear late or flicker. Remote clients would feel that most.
2. Keep the chip but show the path as written, size/provider/file.jpg, and not just the file name. There's no new I/O. A wrong guess then costs one bad click target, and the text stays readable. The catch is longer chips for real files deep in the tree.

I lean towards 2, since what actually hurts is losing the text the agent wrote. Option 1 is more correct, but the cost looks too high for this. Is either direction acceptable?

[sergical]

Another example of the same thing. An agent wrote:

The logo comes from `integrations.sh/logo/tryprofound.com`, which returns a PNG.

It rendered as a file chip labelled tryprofound.com. The chip looks like a domain, but clicking it opens a file that doesn't exist.

This one is narrower than size/provider/file.jpg, and a text rule does exist for it. inlineCodeFilePathCandidate already rejects relative paths whose first segment looks like a hostname. looksLikeHostname("integrations.sh") returns false only because sh is in neither TLD list, and sh is probably left out on purpose because it's also a file extension. Then .com on the last segment passes as a file extension.

A guard on the basename would catch it without touching sh: reject the candidate when the last segment is a hostname with a generic TLD (tryprofound.com, example.io). Repos almost never have files ending in .com, .io or .dev, so I don't expect it to hit real files. This covers only hostname-shaped paths and does not fix the general relative-path case. Option 2 would still help here, since the chip would show the whole text the agent wrote.