◇ Could this help me?
Yes. The diagnosis is correct on both counts: oversized files force irrelevant context into every edit, and duplicated logic turns one bug into several, and phasing the restructure is the right response because it keeps each change small enough to verify. The essential piece missing from the advice is tests: on an untested codebase, doing it in phases reduces how much breaks at once but still gives you no way to tell a clean move from a silent rewrite, so write characterization tests for the behavior being moved before the first phase, and commit after each one so a bad phase can be reverted alone. General practice.
This project grew as one large file with logic copy-pasted in several places, and it breaks whenever I change anything. Do not reorganize it yet. First, map what is actually in the file: the distinct responsibilities, and every place the same logic appears more than once. Second, propose a phased restructuring plan where each phase is small enough that I can verify the app still works before the next one starts, and tell me what could break in each phase. Third, for the first phase only, write tests that capture the current behavior of the code being moved, so we can prove the move did not change it. Wait for my approval between phases and commit after each one.