`glob` tool false-negatives on any multi-segment pattern unless prefixed with `**/`

Describe the bug

The built-in glob tool returns "No files matched the pattern." for any
pattern containing a path separator, unless the pattern is prefixed with
**/. Literal relative paths (2026/07/26.md) and wildcarded multi-segment
patterns (2026/07/*.md) both fail even though the files exist directly under
the given paths root. Single-segment patterns (inbox.md, *.md) and
**/-prefixed patterns work.

This is worse than an inconvenience: the agent trusts the empty result. In one
session the agent checked for a file with its exact relative path, got no
match, and confidently declared the file missing — then acted on that false
premise.

Affected version

1.0.70-0 (running as the VS Code Agent Sessions CLI backend; macOS arm64)

Steps to reproduce the behavior

Against a repo containing 2026/07/26.md and inbox.md at the root:

1. glob with pattern: "2026/07/26.md", paths: ["<repo>"] →
   No files matched the pattern. (file exists)
2. glob with pattern: "2026/07/*.md", same paths →
   No files matched the pattern. (31 files exist there)
3. glob with pattern: "**/07/26.md", same paths →
   <repo>/2026/07/26.md ✔
4. glob with pattern: "inbox.md", same paths →
   <repo>/inbox.md ✔

So the failure is specifically: multi-segment pattern not prefixed with
**/. It looks like the matcher compares patterns against basenames (or a
single path segment) unless a globstar forces full-path matching.

Expected behavior

A relative pattern is resolved against the given paths roots, per standard
glob semantics: 2026/07/26.md matches <root>/2026/07/26.md. At minimum,
the tool description should say patterns must be **/-prefixed to traverse
directories — but fixing the matching is much better than documenting the
trap, since empty results are treated as evidence of absence.

Additional context

• OS: macOS 26.5.2, arm64
• Observed both from VS Code Agent Sessions and reproduced deterministically
  (4 calls above, same session, seconds apart)

Start by locating the built-in glob tool and its path-matching implementation, then reproduce the four patterns from the issue against a repository containing the listed files. Trace how relative patterns are compared with the paths roots. Done means multi-segment relative patterns match existing files while the existing single-segment and **/ cases continue to work.