`pyrefly coverage` should respect `project-excludes` from the config

NumPy's `pyproject.toml`
([src](https://github.com/numpy/numpy/blob/aadc23fc63cbcbe3ff71a2853e984f59a79a6429/pyproject.toml#L282-L284)) looks like this:

```toml
[tool.pyrefly]
project-includes = ["numpy/**/*.pyi"]
project-excludes = ["numpy/typing/tests/**"]
```

But `pyrefly coverage check numpy` (`pyrefly==1.1.1`) still reports symbols from `numpy/typing/tests/**`. They only disappear if I repeat the glob on the CLI with `--project-excludes="numpy/typing/tests/**"`.

I know passing a path switches to [single-file mode](https://pyrefly.org/en/docs/configuration/#type-checking-modes), where config `project-includes`/`project-excludes` are ignored (same as #1360, closed as by-design). But dropping the excludes is surprising for `coverage`: pointing it at a package while keeping the project's `tests/**` excludes seems like a pretty natural thing to want. I, at least, fully expected this to "just work", and had to spend a lot of time figuring out that it had to do with the `numpy` path I specified, and that using `pyrefly coverage check` (without the `numpy` path) will respect the configured `project-excludes`.

The [docs](https://pyrefly.org/en/docs/configuration/#type-checking-modes) justify this behavior by files resolving to different configs. But there's no ambiguity when there's a single config at the root, which I expect to be the most common scenario in practice.

So I propose that, in "single-file mode", the config's `project-excludes` still apply when all files resolve to the same config (still ignoring `project-includes`, since the path already narrows those).

Since this is broader than just `pyrefly coverage`, I'll wait to see what you think about this before I'll start working on a PR.