Space permissions for an add-on custom content are incorrect

Issue Summary

Space permission header's wording seems switched as confirmed from aria attributes and rest endpoint response:

• Space Permission

• Rest endpoint response

That is, the first header should be about "Document Read Request" and not "Document Read Confirmation" and vice versa.

Steps to Reproduce

1. Install a Confluence Connect app that has at least two custom content types with configurable space permissions (apiSupport.supportedSpacePermissions = ["create", "read", "delete"] in the descriptor, docs for those fields are here https://developer.atlassian.com/cloud/confluence/modules/custom-content/). You can use our app Scroll Documents for Confluence Cloud to test this (https://marketplace.atlassian.com/apps/1217608/scroll-documents-for-confluence?hosting=cloud), which is also where we encountered the problem, although I think it's not specific to this app.
2. Go to the page for configuring add-on space permissions (Space Setting > Permissions > Add-on, /spaces/addonpermissions.action?key=<space-key>).
3. Change the space permissions for the first custom content type (Document Read Confirmations in our app) and observe the effect (you can check it through the REST API /rest/api/space/<space-key>?expand=permissions)
4. Do the same thing for the second content type (Document Read Requests in our app) and observe the effect.

Expected Results

The cells under the header text for the first type (Document Read Confirmations) control the permissions of the first type and the cells under the header text for the second type (Document Read Requests) control the permissons of the second type.

Actual Results

The relationships or headers are reversed. Concretely, the cells under "Document Read Confirmations" control the read request permissions and the cells under "Document Read Requests" control the read confirmation permissions.

Notes

• From vendor: Note that you can also see that something is wrong by inspecting the DOM tree in your browser. The table cells have a data-permission attribute that identifies the permission that they control. See if it matches what the header says.
• From vendor: This issue very confusing to the user and may lead to accidental misconfiguration.

Workaround

Assume that the second column is the first column