I would imagine why the types were chosen could easily be explained in the commit message. The goal presumably (at least how I do it) is so that if I'm touching quite a lot of the code base, the reviewer has the _option_ of being taken through the narrative of the change like they might explain if they were talking to you. If you don't want to be told what the changes are and how they tie together, then just click on review changes and review it all at once. It's not about the clean history, it's about making the reviewer's life easier with larger features.

The commits might get squashed anyways so the history on main won't necessarily match what's on the feature branch.

You can commit before you raise a pull request, I don't quite understand that point but I might just be missing something about your workflow that's different to mine.