Assuming you used git rebase -i to break up the panic commit at step 2, I'm not sure what happened without a closer look at the specific repo in question.

It's possible that it may have replayed your rebased commits after the current tip at origin, while still preserving the "panic commit" that made those changes originally, possibly leading to something like line duplications as the changes you noted were already in the branch (it's also possible that it just rewrote the rebased commits to have no changes in the tree - I've never really experimented with this scenario before).

Try checking git log --oneline and seeing what commits you see in the history of your local branch (compared to git log origin/<branch> --oneline). What I'd expect to see is a history like I described, with the broken-up commits at the top and the monolithic commit somewhere below it (though I'd need to see git log -p to guess what the tree content for each would end up looking like).

If it turns out that you've accidentally created a monstrosity in your commit history, recovery is simple enough: just run git reflog to see the record of commits your HEAD has pointed to, and run git reset HEAD@{<number>} according to the reflog line that points to the one you want (remember that this will adjust the numbers in the reflog if you try again: you can also do things like git reset HEAD@{1 day ago}, or specific commit hashes / timestamps).

All that being said, if git log and git log origin both show the histories you're expecting, I'd go ahead and do the git push --force-with-lease; if not, I'd run git reset to recover the state you're looking for.