Fallow glob lets repository content probe paths outside project root

### Impact Fallow expands some globs from the analyzed repository on disk. Before 3.34.0, a segment such as `.*`, `.?` or `..*` in such a glob also matched the special `..` entry. The `glob` crate tests `..` against a segment that starts with a literal `.`. Fallow validates plugin glob patterns and refuses absolute paths and `..` segments, but these segments passed that validation. The attacker controls the repository content. The attacker must also be able to read the Fallow output, for example a CI log or a pull request comment. Then the attacker can learn if a file or directory exists in the parent of the project root: - A plugin `fileExists` detection pattern such as `.*/marker.json` made the plugin active when `marker.json` existed in the parent directory. - An external plugin `configPatterns` or `alwaysUsed` pattern could match a config file in the parent directory. When the plugin was active and declared `toolingDependencies`, the tooling detection credited the related dev dependency. An unused dependency finding could then disappear, and `--trace-dependency` printed the outside path. - `fallow plugin-check` reported `path_exists: true` for a seeded entry that matched only in the parent directory. Fallow tested only that these paths exist. It did not read or print the content of a file outside the project root through these globs. The Jest, Vitest and Rstest project globs had the same `.*` problem, and the Jest and Vitest ones also read file content. GHSA-jfwm-3p3c-6hx5 describes that case. ### Patches Fixed in 3.34.0. Fallow now rewrites a leading `.` in a wildcard segment to `[.]` before it expands the glob on disk. `[.]` matches the same hidden files and directories inside the project root. The `glob` crate does not test `..` against it. ### Workarounds Run Fallow only on repositories that you trust. Before you run Fallow on another repository, check the `detection`, `configPatterns` and `alwaysUsed` patterns of its plugin files.