Images do not load when copying a page again via REST API (Preview Unavailable)

Issue Summary

When copying a page with an image using the copy single page REST API endpoint, and overwriting it afterwards, causes a bug that the image is not displayed in the page for logged in users (different from the one who copied the page).  

There's a similar bug that occurred https://jira.atlassian.com/browse/CONFCLOUD-73078, however it involved anonymous users. 

Steps to Reproduce

1. Create a page in a parent space with attachments (images).
2. Create another space that is public (Public Space).
3. Copy across the page using the Copy endpoint in the Confluence REST API

   curl --location --request POST 'https://<BASE_URL>/wiki/rest/api/content/<PAGE_ID>/copy' \
   2--header 'Authorization: Basic <‘AUTH_KEY> \
   3--header 'Content-Type: application/json' \
   4--data-raw '{
   5    "copyAttachments": true,
   6    "copyPermissions": true,
   7    "copyLabels": false,
   8    "copyCustomContents": true,
   9    "copyProperties": false,
   10    "destination": {
   11        "type": "parent_page",
   12        "value": <HOMEPAGE ID OF TARGET SPACE>
   13    }
   14}'

1. Update the target page. DO NOT remove any of the images.
2. Overwrite the copy via the copy endpoint bellow, and then try accessing the page with the image using a different user

curl --location --request POST 'https://<BASE_URL>/wiki/rest/api/content/<PAGE_ID>/copy' \
2--header 'Authorization: Basic <‘AUTH_KEY> \
3--header 'Content-Type: application/json' \
4--data-raw '{
5    "copyAttachments": true,
6    "copyPermissions": true,
7    "copyLabels": false,
8    "copyCustomContents": true,
9    "copyProperties": false,
10    "destination": {
11        "type": “existing_page",
12        "value": <PAGE ID OF COPY IN TARGET SPACE>
13    }
14}'

Expected Results

Page is updated having the image displayed correctly.

Actual Results

The image is not displayed, and when the preview is opened shows preview unavailable.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available