ci: Add Pyright static type checking workflow

[KarimAziev]

This pull request introduces Pyright, a static type-checking tool for Python, into the GitHub Actions CI pipeline.

As part of addressing issue #1192, this addition encourages gradual improvements in type annotations while providing developers with immediate feedback on type-related issues.

At this stage, the pipeline warns about type issues and doesn’t enforce strict checking. This is intentional to allow gradual type annotation improvements over time.

[davidplowman]

Thanks, that's really great! One further thought... do you know if it would be possible to install this check as part of our pre-commit hook? Not essential, I guess, but it might be nice to be told about errors before creating a pull request.

Edit: Ah, I see. Looks like I can add it to the .pre-commit-config.yaml file. I'll try that!

[KarimAziev]

Yes, you're correct that it is possible to integrate Pyright into the pre-commit hooks via the .pre-commit-config.yaml file. However, it might be too early to consider adding it to the pre-commit workflow at this stage.

When I initially added Pyright to the CI for this repository, it detected around 400 type-related issues. To avoid blocking progress, these issues were downgraded to warnings for now, providing visibility without enforcing strict type-checking.

Adding Pyright as a strict pre-commit check at this point might create unnecessary friction for contributors, as many existing warnings could interfere with commit workflows. An alternative approach could be to encourage developers to configure their IDEs to use Pyright, allowing them to see and fix warnings incrementally while working on the codebase.

A potential strategy could involve enabling stricter checks incrementally. For example, starting with reportReturnType as an error (which would raise ~20 manageable errors) could help enforce type safety gradually without overwhelming contributors.

Once the majority of issues are addressed and warnings are cleaned up, it might make sense to revisit the idea of adding Pyright to the pre-commit hooks as a way to enforce stricter type-checking for new changes. For now, though, an incremental improvement process seems more practical.

[davidplowman]

Yes, those are good points. Maybe I'll just start using it locally, figure out how to start enabling just a few things, and see how it goes for a bit. Thanks!