Add pyrefly for type checking

[pavelzw]

Citing #2593 (comment)

I would feel more comfortable adding an autoupdater for py-rattler pinnings if we had type checking as mentioned in #2589 (comment)

In the current state of this repo, probably all occurrences of py-rattler are covered by unit tests(?) so we would catch issues in the PR anyway but if py-rattler usage grows, there might be some hidden branches that are not covered by the testing suite and latest then I think type checking is needed.

(I'm in general a fan of being able to see the types of something when working within my IDE, if this is properly supported in the project through type checkers, I'm all for it)

[pavelzw]

Cc @h-vetinari

[h-vetinari]

Copying a comment from #2593

---

@isuruf: Unfortunately the first three files in the diff I looked at are false positives. Does adding more checks justify having to workaround false positives?

I know what you mean; I noted above

@h-vetinari: some of these fixes look a bit doubtful in terms of benefit, but nothing I'm actually opposed to.

However, this is IMO a bit like formatting questions with black, i.e. not really worth arguing about, if someone thought about a structural approach and considers it worth linting.

pyrefly should help with topics like #2589, so that'd be an upside for which I could live with the opinionated-but-unnecessary changes. On the other hand, we could perhaps do this differently (e.g. mypy; tough I don't claim to know the differences between that and pyrefly).

There's also a possibility to create an exceptions file (see #2591, which has "passing" pyrefly checks despite not fixing anything), though this would currently be >2600 lines long. Since the those exceptions are very granular - e.g.

    {
      "line": 172,
      "column": 72,
      "stop_line": 172,
      "stop_column": 74,
      "path": "conda_smithy/anaconda_token_rotation.py",
      "code": -2,
      "name": "unbound-name",
      "description": "`gh` may be uninitialized",
      "concise_description": "`gh` may be uninitialized",
      "severity": "error"
    },

this sounds like something we'd have to keep up-to-date somewhat laboriously (though perhaps there's automation for that), so I'd rather just get rid of these errors; assuming we want to adopt pyrefly.