Fix __unknown__ module names for files without a config

[jorenham]

Summary

CLI handles were named without checking the config's fallback_search_path, so in a directory without a config every file was __unknown__, and no symbol FQN could match the public FQNs in pyrefly coverage {check, report} --public-only.
ConfigFile::handle_from_module_path now applies its own fallback_search_path (i.e. what the LSP already did), so that handle_from_module_path_with_fallback is now no longer needed.

Fixes #4132

Test Plan

Regression test added, and verified that pyrefly coverage check --public-only in a directory without pyrefly config now reports the same as without --public-only.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[meta-codesync]

@kinto0 has imported this pull request. If you are a Meta employee, you can view this in D111830464.

[stroxler]

Review automatically exported from Phabricator review in Meta.

[connernilsen]

Review automatically exported from Phabricator review in Meta.

[kinto0]

one more question (and an alternate approach suggestion):

what project doesn't work with coverage? I expect projects that don't work on coverage to also have name issues with pyrefly check. can I test it?

We wanted to keep __unknown__ as a means to detect when imports couldn't be determined. by adding fallback_search_path, we support imports that don't work in normal python (for example, subdir1 using a different import root than subdir2).

If we find that this is an issue in coverage and not check, I'd like to limit this change to coverage doing something like #4150