when you write "should get cached", do you mean cached at the dispatcher level? The dispatcher caches files with its full path (taken from the URL) below the configured docroot. That means:https://www.hostname.internal/page.html => $DOCROOT/page.htmlhttps://www.hostname.internal/path/to/page.html =>...

IIRC /conf does not know about runmodes. 

It seems that CRXDE Lite should be a more resilient in this area... This request does not actually perform the replication, but is rather reading the replication status (I don't the know frontend code of CRXDE Lite good enough to say if this always happens after the replication request has been done...

Yes, it will be removed soon (loglevel degraded to DEBUG)

I would rely on a dedicated IDP, because these provide this feature ootb.  Of course you can build something like this also in AEM, but it requires quite a bit of work to make it work properly.

How did you find those vulnerabilities? Were you just scanning your application or were you scaning the uber.jar file of AEM? Or even scanning the AEM instance itself (or SDK)? In any way, I would check with Adobe support.

What configuration parameter do you want to add per tenant?

That approach is not compatible with AEM CS. May I ask why you try to achieve this?

 I would start at the very basics:does the Java process still run?can you do a "jstack <pid of the java process>"?can you access the instance via jconsole?can you access the OSGI webconsole?

It's just a warning.(I have seen to often code, which assumes that every page as jcr:content child node. According to the number of warnings I see this is not always the case.)