Feature request: Warn on unrecognized config keys

[sentiasm]

Describe the Bug

I copied some config over from mypy into my pyproject.toml and wrote python_version instead of the python-version that pyrefly expects. The key was silently ignored, so I spent a while confused about why my Python version setting had no effect. A warning would have caught it immediately.

I think this would also make pyrefly more internally consistent: an unknown error kind already fails to parse (e.g. unknown variant 'unreachable-match-case'), but an unknown top-level key is silently dropped. It looks like the top-level config struct doesn't reject unknown fields the way the error-kinds enum does.

I'd suggest a warning rather than a hard error — that catches typos without breaking configs shared across pyrefly versions (e.g. a newer key being read by an older binary).

Sandbox Link

No response

(Only applicable for extension issues) IDE Information

No response

[hiSandog]

A warning with a closest-key suggestion would be a good fit here. For example, python_version could warn as unknown and suggest python-version, while still allowing unknown keys when users intentionally share config across tools or versions. It may be worth supporting an explicit ignore list or namespaced escape hatch so forward-compatible configs can stay quiet without making typos silent again.

[yangdanny97]

That sounds like a useful feature. We were just talking about building out some limited TOML support in the language server to enable this in the IDE as well, but I guess the CLI could be a good starting point.

[markselby9]

I took a shot at this in #3966 — one warning per unrecognized key with a closest-key "did you mean" suggestion (scoped so a [[sub-config]] typo won't suggest a project-only key). Reuses the existing edit-distance ranking from pyrefly_util::suggest. Happy to adjust the wording or approach.