forceRerunTriggers never matches when the project path contains a dot-directory segment (picomatch dot:false on absolute paths)

Describe the bug

vitest run --changed consults forceRerunTriggers in filterTestsBySource — but it matches the changed files' absolute paths with picomatch at its default dot: false. If any segment of the project's path begins with a dot (a clone into .app/, ~/.local/src/…, an agent worktree under .claude/worktrees/…), ** refuses to cross that segment and every trigger silently fails to match — even a literal '**/*' (verified by instrumenting the built chunk: related contained the changed package.json, the trigger list contained '**/*', and matcher(file) returned false for every entry).

Consequence: the documented escalation to the full suite on package.json / lockfile / config changes never happens in such checkouts, with no warning — --changed quietly reports No test files found for a dependency-only change. The same project in a dot-free directory escalates correctly, so the behavior is position-dependent and very hard to notice. (We hit this in CI-adjacent tooling: a lockfile-changing push ran 7 test files instead of 530 and shipped a break only the full suite catches.)

The dot must lead a path segment: clone-.app (mid-name dot) still matches; .app does not — consistent with picomatch's dot: false semantics.

In the built output (dist/chunks/cli-api.*.js, v4.1.11):

const matcher = forceRerunTriggers.length ? pm(forceRerunTriggers) : void 0;
if (matcher && related.some((file) => matcher(file))) return specs;

Patching this call to pm(forceRerunTriggers, { dot: true }) makes both clones in the reproduction behave identically. The watch-mode check (pm.isMatch(filepath, this.vitest.config.forceRerunTriggers)) has the same shape and presumably the same blind spot.

What I expect: a trigger like **/package.json/** (vitest's own default) fires regardless of whether the project happens to live under a dot-named directory — or, if dot: false is intentional here, that the docs say so.

Happy to submit a PR (add { dot: true } at both call sites + a test) if you confirm that's the intended semantics.

Reproduction

https://github.com/digitalcostas/vitest-forcereruntriggers-dot-dir-repro

Two clones of the same 4-file project (one test, config declaring vitest's own default triggers explicitly):

git clone https://github.com/digitalcostas/vitest-forcereruntriggers-dot-dir-repro app
cd app && npm i
node -e "const fs=require('fs');const j=JSON.parse(fs.readFileSync('package.json'));j.description='trigger';fs.writeFileSync('package.json',JSON.stringify(j,null,2))"
npx vitest run --changed HEAD
#  → Test Files  1 passed (1)          ← trigger matched, suite ran
cd .. && git clone https://github.com/digitalcostas/vitest-forcereruntriggers-dot-dir-repro .app
cd .app && npm i
node -e "const fs=require('fs');const j=JSON.parse(fs.readFileSync('package.json'));j.description='trigger';fs.writeFileSync('package.json',JSON.stringify(j,null,2))"
npx vitest run --changed HEAD
#  → No test files found, exiting with code 0    ← identical change, trigger silently ignored

System Info

  System:
    OS: macOS 26.6.2
    CPU: (8) arm64 Apple M1
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.15.0
    npm: 11.12.1
    pnpm: 10.4.1
  npmPackages:
    vitest: ^4.1.11 => 4.1.11 (repro); also confirmed on 4.0.16

Used Package Manager

npm (repro); pnpm (where originally hit)

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

Start at the filterTestsBySource entry point and compare it with the watch-mode check that calls picomatch for forceRerunTriggers. Reproduce the package.json change in both the dot-free and .app checkouts, then add regression coverage showing that a trigger runs the full suite from a dot-directory path and verify the changed-file behavior.