I see you've identified the following problems:
Repository layer sends raw data from the network api to the ViewModel forcing VM to do transformation and formatting making VM hard to test
A "God Repository" that is referenced in a large number of places throughout the codebase
Data transformation logic varies across different consumers (ViewModels), so there’s no single, consistent transformation
You've listed some solutions that sound like they'd help. But let me propose something:
Create behavior code that doesn't know how to find anything, doesn't transform the format of anything, and doesn't decide where to put anything. It does one thing, on the one format it expects, that gets handed to it, and puts it wherever its told to put it.
This is not what a use case does. A use case knows where to find everything. Knows where to put everything. Knows how to transform everything. And that's fine. A use case can use the above behavior code to do its work.
What this does is separate behavior from knowledge of the world. That way when the world changes the behavior is minimally impacted. It also makes the behavior code easier to read and test since you can drop it into any world you like. Even a testing one.
Doing that will push back on all three of your problems.
When your behavior code insists on a single format you're forced to do the transformation first, outside of it. This avoids crazy conditionals or weird parsing in the behavior code.
This pushes knowledge of all the repositories away from the behavior code
Since all behavior code insists on its own format, transformation logic is pushed out.
But there is more work to do. What you call a "God Repository" reminds me of a service locator. The cure for that is dependency injection. I've talked about that before.
You talked about work being done in little helper methods. Consider maintaining the separation they were providing but be willing to make these into full fledged objects. Give your behavior code some respect.