Yikes! "Bring changes to new branch" -- lost tons of uncommitted code

### Describe the bug

Steps:

- Made many uncommitted changes to my own "master" fork of an upstream "master" repo: changed and added many files, changed many directory names
- Decided to bring the changes to a new "feature" branch, on my own repo.
- Clicked New Branch in GitHub Desktop, created the "feature" branch
- Clicked "Bring my changes to the new branch" not "Stash changes on current branch"
- New branch was automatically re-based on an upstream master, not my working "master" forked repo.
- Many merge conflicts, obviously
- Tried to commit changes to new branch, but not possible (thankfully!) - merge conflicts reported unresolvable

Then i noticed the missing directories and hundreds of missing changed/added files

### Version & OS

GitHub Desktop 2.4.3
MacOS 10.14.6 Mojave

This seems to parallel issues #9140, #9038, and #8084

Please advise. I would like to switch to my former working "master" branch to find out if changes were stashed, but it seems i am blocked from switching branches until i resolve merge conflicts in the new "feature" branch.

I don't actually want these changes going to the new branch because of the missing files/directories - I would like to first commit my uncommitted changes to the previous "master" branch for safekeeping.

It's 3 days work that seems to have vanished.

### More detail

I'm aware that from the point of viee of the upstream master, these were untracked files, but here is an outline of what was lost or updated. Losing untracked files would be of course expected, if i were not trying to bring the changes to the new branch.

Let's say these are some of the files i worked on, from my working "master" branch:

```
/old-folder1
--old-file-name1
/old-folder2
--old-file-name2
/old-folder3
--old-file-name3

```

And all the files had uncommitted changes, with some directories and filenames changed:

```
/old-folder-rename1
--old-file-rename1
/old-folder-2
--old-file-rename2
/old-folder3
--old-file-name3
/new-folder4
--new-file-name4

```
New branch only has these changes:

```
/old-folder-rename1 = IGNORED, VANISHED FROM REPO
--old-file-rename1 = IGNORED, VANISHED FROM REPO
/old-folder1 = UNCHANGED
--old-file-name1 = UNCHANGED
/old-folder2
--old-file-rename2 = NOTICED, REQUIRES COMMAND LINE ADD
/old-folder3
--old-file-name3 = OK, CHANGES DIFFED IN GITHUB DESKTOP
/new-folder4 = IGNORED, VANISHED FROM REPO
--new-file-name4 = IGNORED, VANISHED FROM REPO
```

Again, I haven't committed anything, so maybe unstaging the changes to the new branch (via a soft reset) will work, and then i can switch branches and see what's going on.

The issue provides reproduction steps for GitHub Desktop 2.4.3 on macOS 10.14.6, involving uncommitted renames, added files, and the New Branch flow. Start by reproducing the Bring my changes to the new branch action with similar changes and compare it with the expected branch state. Done means all uncommitted changes are preserved and the user can recover or switch branches safely.

Written by the indexing model from the issue text.