aemaacs : Issue with replication for non admin user

We are experiencing an issue in our AEM as a Cloud Service environment  where non-admin authors are unable to use standard publishing due to an implicit system path reference.When a user attempts to publish a content page, the replication payload automatically appends a reference to the legacy system path /libs/settings/wcm/designs/default/jcr:content. Because /libs is immutable and standard users lack crx:replicate permissions at the root/libs level, the replication engine blocks the direct publish and routes the payload to the default request_for_activation workflow.To isolate this issue, we created a dedicated test user and explicitly granted them jcr:all permissions on the following paths:/var  & /content/dam/mygps/en/pi  & /content/mygps/us/en/pi (Plus standard jcr:read on root /) Despite having full jcr:all (which includes read, write, and replicate) across all relevant content and variable directories, this test user still triggers the approval workflow. The replication engine blocks the action solely because the payload tries to sweep in the system design file under /libs, where permissions cannot be modified in Cloud environments.We need your assistance to determine if there is an out-of-the-box configuration, a product patch, or an OSGi setting we can apply to prevent standard pages from dragging /libs/settings/wcm/designs/default into the replication queue.

Cloud log:

21.07.2026 01:31:17.831 *INFO* [com.day.cq.wcm.workflow.impl.wcmworkflowserviceimpl] com.adobe.granite.workflow.core.WorkflowSessionImpl Starting workflow with model: /var/workflow/models/request_for_activation and payload: /libs/settings/wcm/designs/default/jcr:content

21.07.2026 01:31:17.831 *WARN* [com.day.cq.wcm.workflow.impl.wcmworkflowserviceimpl] com.adobe.granite.workflow.core.WorkflowSessionImpl No content fragment IDs found for workflow model: /var/workflow/models/request_for_activation and payload: /libs/settings/wcm/designs/default/