Embedded client in OSF page searching for a PDF fingerprint that does not match the PDF on the page

[mkdir-washington-edu]

Describe the bug
When visiting https://osf.io/preprints/metaarxiv/cd5j9/ annotations appear in the embedded app in Public that belong to a different page.

The page https://osf.io/preprints/metaarxiv/cd5j9/ has a document_id of 1508122. The only annotations on that document_if are in a private group, group.id = 68313. No PDF fingerprint has been recorded on the document_uri table for that document_id, but the Console reports a fingerprint of 22b24cb50f2b8e42ae17629cd0e0166c. /search/ on the page has the following request URL:
https://hypothes.is/api/search?_separate_replies=false&group=__world__&limit=50&order=asc&sort=created&uri=https%3A%2F%2Fosf.io%2Fpreprints%2Fmetaarxiv%2Fcd5j9%2F&uri=urn%3Ax-pdf%3A3b67a8f9a67e369c0b9936dac10cabb6c72d4d56045f9ce4bb6826311993fb16

One of the annotations in Public on that page is: https://hyp.is/TzrxwnVhEemnqNt0a1u6Rg/osf.io/sfc38/. This annotation is associated with document_id = 202207. This document_id is associated with httpx://osf.io/sfc38, httpx://osf.io, and several PDF fingerprints. One of those fingerprints is urn:x-pdf:3b67a8f9a67e369c0b9936dac10cabb6c72d4d56045f9ce4bb6826311993fb16, which is being searched.

So it seems /search/ is looking for the correct URL, but not for the PDF fingerprint that the web Console is picking up, but rather a different fingerprint not currently associated with the URL.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://osf.io/preprints/metaarxiv/cd5j9/
2. In the embedded client on that page open the Public folder.
3. See annotations from document_id = 202207
4. See /search/ on that page.

Expected behavior
I would expect /search/ to use the PDF fingerprint for the PDF embedded on the page.

Screenshots

Desktop (please complete the following information):

• Browser: Chrome 89
• OS: Mac OS 10.14

Additional context
https://twitter.com/BreznauNate/status/1382558665417318401

[mkdir-washington-edu]

Might be related to https://github.com/hypothesis/support/issues/194

[mkdir-washington-edu]

https://app.hubspot.com/contacts/6291320/ticket/383286953
Related: someone who helps manage OSF wrote in saying they think the users experiencing this are running an extension interfering with the page. However, since I wrote this issue up the problem now exists in Chrome 89 and Firefox 88 as well as Safari 14.