Update - I wrote the original answer in two phases, and as such it's a little confusing. The information remains the same, but I'm cleaning it up a bit...
Depending on how you squashed the commits, you have one of two very similar situations. Roughly speaking:
1) If you squashed from one branch to another (e.g. by git merge --aquash), you have a graph like
x -- AB!MCD -- E <--(branch_for_pr)
A -- B -- !M -- C -- D <--(work_branch)
where !M reverted some previous merge, and AB!MCD is a "squash" of A, B, !M, C, and D.
2) If you squashed the commits "in place" on a branch, e.g. git rebase -i, the graph is more like
x -- AB!MCD -- E <--(branch_for_pr)
A -- B -- !M -- C -- D <--(branch_for_pr@{2})
Here branch_for_pr@{2} is a reflog entry. The tools don't show reflog entries as visibly as current refs, so it might appear as though A..D are "gone", but (at least on the local clone where the squash occurred) they hopefully aren't. (It is true that reflog entries eventually expire - by default after about 3 months, or when you explicitly expire them. After the reflog entry expires, gc could delete the old commits unless, in the mean time, you've done something that keeps them "reachable". Also, reflogs aren't shared on push or fetch.)
You would find the reflog entry with a command like
git reflog branch_for_pr
and could then put a new branch or tag on it until you know you no longer need it, to remove the risk that reflog expiry would hide it from you. If you do that, the result would look like the first diagram (from (1) above).
The rest of this entry assumes an actual branch points to D. So... how to proceed?
The easiest thing to do is to revert !M on branch_for_pr. This may seem counter-intuitive, but you can revert just about anything; it doesn't have to be an ancestor of HEAD. So you need an expression that resolves to !M - which can be its commit ID, or in this example something like work_branch~2.
git checkout branch_for_pr
git revert work_branch~2
A few points of background to know here:
A commit is just a snapshot of a project with a small amount of metadata. The metadata includes a "parent" list, which places the snapshot relative to other snapshots in history. Many git commands operate on a commit's patch - i.e. the difference between that commit and its parent (or one of its parents, in the case of merges). A commit's metadata does not include any special relationship to "commit reverted by this commit", or "commit(s) squashed into this commit"; that information is essentially lost.
As implied above, a "revert" is just a short-hand way to assemble a commit which relates to its parent in a certain way, governed by another commit's relationship with its parent. git does not memorialize that this particular commit was generated by reverting another commit (much less what that other commit was).
Likewise, a "squash" is just a shorthand way of specifying a group of changes you want to apply to HEAD to create a new commit. The resulting commit doesn't "know" that it is a squash.
So those things might change the way you think about what you're trying to do, and affect how you approach this question. And yet a more immediate problem for the proposed solution of "re-doing the merge" is, git is a little weird about reverts of merges. Once you've reverted a merge, it' snot so easy to re-merge it. You either have to regenerate the branch from new commits (to make a re-merge possible), or just revert the revert - which is what I recommend doing above, directly on your final branch.
There are many variations on this idea, which may produce "cleaner" histories; but this is the simplest and avoids possibly muddying things even more.
