[BUG] Glob tool returns no results when pattern starts with a literal subdirectory name

Problem

The Glob tool returns "No files found" when the search pattern begins with a literal (non-dot) directory name, even though the directory exists, is tracked by git, and is not gitignored.

Patterns starting with **/ work correctly for the same files.

Reproduction

Given a repo with structure:

project/
  openspec/
    config.yaml
    specs/
      system-overview.md
      daily-pipeline.md
      ...

| Pattern | path param | Result | Expected |
|---|---|---|---|
| openspec/* | project root | No files found | Should find config.yaml etc. |
| openspec/** | project root | No files found | Should find all files |
| openspec/specs/*.md | project root | No files found | Should find .md files |
| openspec/**/*.md | project root | No files found | Should find .md files |
| **/openspec* | project root | No files found | Should find directory |
| **/*.yaml | project root | Finds openspec\config.yaml | ✓ |
| **/specs/*.md | project root | Finds all .md files | ✓ |
| **/config.yaml | project root | Finds openspec\config.yaml | ✓ |

Relation to #33999

Issue #33999 documents the same class of bug for dot-directories (.claude/**/*), traced to Bun.Glob.scan() skipping directories during traversal. This issue shows the problem extends to non-dot directories when named explicitly at the start of a pattern. The suggested fix in #33999 (dot: true) would not resolve this case.

Workarounds

• Start all patterns with **/ instead of a directory name
• Use ls or find via Bash for directory-specific searches

Environment

• Claude Code on Windows 11 (bash shell)
• Directory is git-tracked, not in any .gitignore