Adding a link to a page with the copy API causes the link not to work after the linked page is created

Issue Summary

Adding a link to a page with the copy API causes the link not to work after the linked page is created.

Steps to Reproduce

1. Copy the page by setting a link in the body

   curl --request POST \
     --url '<site>/wiki/rest/api/content/406650881/copy' \
     --header 'Accept: application/json;charset=UTF-8' \
     --header 'Content-Type: application/json' \
     --data '{
      "copyAttachments": true,
      "copyPermissions": false,
      "copyProperties": false,
      "copyLabels": true,
      "copyCustomContents": false,
      "destination": {
        "type": "parent_page",
        "value": "406781953"
      },
      "pageTitle": "TargetPage",
      "body": {
         "storage": {
          "representation": "storage",
          "value": "<ac:link><ri:page ri:content-title=\"Linked page\"/></ac:link>"
        }
      }
   }' \
   --basic --user '<userEmail>:<token>'
   

2. Create the linked page (called "Linked page" in the example above).

Expected Results

The linked page is opened when clicking on the page content.

If the linked page has not been created yet, a draft page of the page is created and is opened when clicking on the page content.

Actual Results

The linked page is not opened when clicking on the page content.
This is because the URL that the browser tries to open is in this form:
<site>null/pages/createpage.action?spaceKey=~711071095&title=LinkedPage&linkCreation=true&fromPageId=406683652

Notice the null after the <site> in the URL and the wiki part is missing. The correct URL would be:
<site>/wiki/pages/createpage.action?spaceKey=~711071095&title=LinkedPage&linkCreation=true&fromPageId=406683652

Notes

The problem is present regardless of how the "Linked page" is created (e.g. creating the page from the user interface, the /rest/api/content/<source-page-id>/copy API or the /rest/api/content API will all result in the same problem).

Workaround

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