One central distribution point for all the scientific missions and all the GNSS missions is the Crustal Dynamics Data Information System (CDDIS) at NASA Goddard Space Flight Center.
The data are available here: https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/orbit_products.html
The project is described here: https://earthdata.nasa.gov/eosdis/daacs/cddis
There are many different products, some of which are easier to work with than others. Rafa's recent answer and comments on comparing SDP4 & SGP4 with high-precision orbits mentions parsing RINEX for GPS, GLONASS, and DORIS, so you might try starting there.
Registration for an account is necessary, but the site says "EOSDIS data are openly available to all and free of charge except where governed by international agreements."
For turning TLEs into Cartesian vectors, I advise getting the latest SGP4 library from https://www.space-track.org/documentation#/sgp4 (need to be registered for and logged into your free account for the link to work). Release notes for this software package — version 8.2 (dated 15 November 2021) of the ex-USAF, now US Space Force (USSF) Standard Astrodynamics Algorithms Library (SAAL) — says "Fixed some bugs hindering performance. SGP4 v8.2 is now over twice as fast as v8.1 (over four times as fast as v8.0)", so SGP4 does indeed continue to change, even if not by very much at a time.
The library is implemented in Fortran and C/C++, but there are also wrappers provided for C#, Go, Java, Julia, Matlab, Octave, Python, Tcl, and Visual Basic. This list is growing quickly; it was only about half as long when I started posting it here two years ago. The wrappers aren't particularly elegant or intuitive, unless you learned to program in Fortran, so you may prefer to write your own wrapper around their wrapper to make it more "Pythonic", for example, but it gets the job done.
You also get more than just SGP4. For example, the AstroFunc and TimeFunc libraries handle conversions from UTC to TAI to GHA (Greenwich Hour Angle), Keplerian elements to equinoctial to pos-vel to lat-lon, compute positions of sun and moon, polar wander, determine whether a point in near-earth space is sunlit, and so on. Plenty of other packages do all the same things, but if you have ever worried about whether, for example, you're using the correct definition of TEME (True Equator, Mean Equinox) in your coordinate conversion, using the SAAL is at least a decent way to ensure that all the components of the tool set agree with each other's assumptions.
For me personally, I am required to use them at work, because they come from the US Government and Skyfield does not. Having got used to them at work, I now also use (some of) them at home for hobbyist stuff, and I have over time grown somewhat fond of them, though I am also quite irritated by their continuing preference for confusingly defined, fixed length, hard to parse string formats, of which TLE is by no means the only one: How is an input card for SGP4/other astro standards packages crafted?
691928619.184000
in seconds to another time format, but it's another to be sure it's correct down to the level of ~milliseconds. Just for example How to convert J2000 time to UTC in python? has several answers, but are they correct to order millisecond accuracy? Time is hard; time is confusing! $\endgroup$