And there's no reason those code viewing platforms can't be patched to support rust-analyzer's type hints. (Other than developer time prioritization of course.)
The other problem is that everyone is going to want different amounts of type information from the code (editor). As an example right here, Centril turned theirs (rust-analyzer) off and I keep mine (IntelliJ) on. (I loathe visual alignment and thus the toasts don't unalign anything.)
I'd almost compare this to spaces-versus-tabs (I know I know just bear with me for a bit). In a space-indentation world, everyone's view of the code, in all editors, smart or dumb, is going to be the same. In a tab-indentation (space-alignment) world, everyone can set their indentation width to whatever they want, and this setting is per-user per-environment. Of course, "dumb" environments making the "correct" choice will display a horizontal tab eight columns wide, which few people like, but you can still configure any decent environment to display the tabs your desired way. It even offers new paradigms such as displaying indentation with emoji! (...sorry)
As is probably clear from that rant, I'm on team tabs for indentation, spaces for alignment. Spaces for both is better than using tabs in alignment (because that removes the benefit of tabs). But spaces are what everyone seems to have agreed on, and what all my editors default to, so going against the grain is more effort than it's worth. And I suspect a unsettling number of tabs-camp people still use spaces because they hit the tab key and think it gives them a tab even as the editor expands it to spaces for them.
Bringing it slightly back on topic: the "best" solution is not dealing with formatting at all, and letting the computer deal with it for you. It's a purely automatable task (except in the edge cases of ad-hoc grammars (macros) and exceptionally repetitive code (such as graphics) (which ideally reduces to macros again)), let the machine do it, focus developer energy on other things, etc.
I draw the parallel because type information is very similar in the amount of how personal it is. Someone with little experience with the language and HM type inference will likely want more type hints then someone who spent their formative developer years in Haskell. Any solution you check into version control will uniquely be available identically everywhere, but it's also impossible to (easily) tweak how much is there.
I know it's not a useful answer, but I think the answer is don't let those 1kloc blobs pass code review. Require functions with a "reasonable complexity" cap (existing lint: clippy::cognitive_complexity) and liberally use subfunctions.
(Case study: I actually triggered that lint in a monster of a function. I split it into its three semantic steps in functions within the function, and it benefitted greatly from it. This included, by necessity, typing a location at the edge of the functions that hadn't been explicitly typed prior.)
There can't be "one true style" for when to use explicit type hints (other than "at least when rustc requires") for the same reason rustfmt's "bulldozer style" reformatting doesn't work in all cases: these subjective metrics are context sensitive and vary by use case and user.
I sympathize with the idea that source code should stand on its own and be simple to consume as a plain text file. But honestly, I don't fully agree. We're long past the age of editing plain text files; everyday text editing tasks are almost as complicated as the most advanced IDE. Google Docs and Microsoft Word are amazingly complicated bits of software to "just" edit a text file. Sure, their WYSIWYG editor embeds more information than our plain-text, monospaced, simple source files, right? Well, there's definitely a lot more context to the process than just the source, otherwise rustc would be a no-op and I'd be very confused by the compile times. If I need a specific few gigs of software so I can submit my assignment and read the feedback (no I'm not salty at all why would you think I am), why can't we incrementally improve code viewing experiences with portable intelligence engines like rust-analyzer?
Source code should be intelligible in plain text. We have to interact with legacy environments all the time, after all. But we have technology (insert SpongeBob gif)! Rather than limit ourselves to the lowest common denominator, we should find ways to bring these complicated tasks into the locations where we have the intelligence system at our fingertips to assist us in understanding the code.
And this isn't a "it'll exist in the future" kind of thing. It exists now in rust-analyzer. You can add it to GitHub with SourceGraph(*). It's a better solution than any manual one will ever be, so why can't it be the solution?
(*) Results not guaranteed. They used to include the RLS by default with the language server integration but iirc disabled it due to performance issues. This was a before rust-analyzer even. Also, FireFox will yell at you that it has permission to execute remote code, because it does; that's how they do their plugins for now. Installing a SourceGraph plugin is the same risk factor as a FireFox extension (though with some additional promised sandboxing), just from a different curator's platform.