Check required-version before parsing rules

[jelle-openai]

Summary

Fixes #19922.

The approach I used is to check the required-version separately before parsing the TOML. This feels a bit ugly because we have to parse the TOML separately, but other approaches I considered seemed worse:

• Put the version validation inside SerDe deserialization for RequiredVersion. But this feels wrong: a required version that doesn't match the current version should still parse. Also, I think this means the user might see more errors than just the one for the version mismatch, when ideally they should only see the version mismatch error.
• Rewrite Options to be much more lenient in parsing everything else (in particular, don't validate rule names). However, this would be a bigger rewrite, and might still cause issues similar to Validate required_version before validating rules #19922 if e.g. a new field is added.

Test Plan

New test cases added.

[MichaReiser]

Nice

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Hmm, the ecosystem changes are a bit surprising. Can you try rebasing on main?

[jelle-openai]

Hm do those changes mean it found more autofixes? That would be weird.

I'll apply your suggested change and merge in with latest main.

[MichaReiser]

Thanks. This is great and nice find with DeTable.

I only have a question whether we need the required_version fallback and if we retain the spans in error messages if the required version fails to parse.

[MichaReiser]

I suspect that we lose the span in the error message compared to when deserializing the value as part of the serde deserialization. I'm inclined to return Ok here and defer to the "full" deserialization in that case.

[jelle-openai]

I'll add a test for this case too.

[jelle-openai]

You were right, changed it as you suggested.

[jelle-openai]

Thanks for the review and merge @MichaReiser!