@yamyam1 Worth knowing up front that what you've described shouldn't have broken anything, going by Microsoft's own wording. The refresh doc is explicit that a move is safe: "You can move the file to another location (using drag and drop, for example) and refresh will continue to work because Power BI still knows the file's item ID." It's the copy that kills it, because "a new instance of the file and new item ID is created."
That's not me dismissing what you found, it's the useful part. It narrows the question from "did it move" to "was it actually a move", and those two look identical afterwards. A drag and drop inside the same library is a real move and keeps the item ID. Anything that went out and came back a different way, so download and re-upload, Save As, a restore from the recycle bin or from a backup, a Move To across libraries or sites, creates a new file object with a new item ID even when the name and the path end up exactly where they started. Somebody putting a file back "where it was" is honestly more likely to have done one of those than a clean drag.
There's a free way to tell which happened and it takes about ten seconds. Open the file in SharePoint and look at Version history. Move To carries the history with it, in Microsoft's words "When you use Move to, the history of the document is copied to the new destination", whereas "When you use Copy to with documents that have version history, only the latest version is copied." So:
If the history runs continuously back past the day this happened, it's the same file with the same item ID, the move isn't your cause, and I'd stop there and look elsewhere.
If the history starts fresh at version 1.0 dated around the incident, it's a new file wearing the old one's name. That's your answer, and it also explains the two things that must be baffling you: why moving it back didn't fix it, and why re-authenticating all four spreadsheets got you nowhere. The credential was never the problem. The thing the model is pointed at stopped existing.
If it's the second one, the repair is on the Power BI side rather than the SharePoint side. Open the model in Desktop, go into Power Query, and look at the Source step for that one spreadsheet. If the URL has sourcedoc= followed by a GUID in it, that GUID is the old file's identity and it's the thing that stopped resolving, so re-navigate to the file through Get Data rather than editing the URL by hand and let it pick up the new identity properly. If the URL is instead a plain folder and filename path with no GUID in it, then this isn't your problem, and it's worth knowing that before you spend an afternoon on it.
One thing that saves time either way: you don't have to guess which of the four it is. Open the semantic model's refresh history in the service and look at the error detail on the failed run, it names the data source it choked on. That's the only one you need to touch.
