Very likely, yes. GitHub marks refs/pull/* as read-only, so a filter-branch plus force-push cannot rewrite them, and every commit a pull request ever pointed at stays reachable. I hit the same thing after rewriting a repository's main branch to remove a co-author trailer: the default branch was clean, but the old commit was still reachable from the pull request page.

GitHub's guide "Removing sensitive data from a repository" covers this step. After the rewrite, you contact GitHub Support through the support portal with the repository, the number of affected pull requests and the first changed commit(s). Support can dereference or delete the affected pull requests and remove cached views. The guide does not say how the contributor icons are computed, so I cannot promise they clear the moment the refs go. But the old pull request refs are the only place those commits still live, so that is the ticket to open. You should not need to delete and recreate the repository.

To check the branch itself from your side: I maintain surviving-lines (https://github.com/Bubblegunn/surviving-lines), a small CLI that lists who wrote the lines still alive at HEAD next to each author's commit share. It reads git blame and git log, so it can confirm what the branch now attributes. It cannot see refs/pull or GitHub's cache.