TL;DR If you want to use the above entitlement in the app store, you will at least have to appeal the rejection (and it might still be turned down).
A quick summary for the sake of future developers reading this: We eventually opened a DTS case to discuss options as advised by app review. The discussion concluded that there are no good options without the above entitlement, the only fix that could be accepted into the app store under this policy being to embed needed trust roots in the code instead of accessing them through the OS.
We verified that narrowing the entitlement to just the lock file
<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
<string>/private/var/db/mds/mds.lock</string>
</array>
is sufficient and this was confirmed by DTS, but this entitlement was likewise rejected by app review as requesting "read-write access to read-only system location".
As app review did not respond to requests to further clarify their policy, we verified that on BigSur a sandboxed app running as root (in this case a network extension) can write to the /private/var/db/mds/mds.lock file (and indeed even other files like /private/var/db/mds/mds-test.lock) and pointed this out to challenge the classification as "read-only system location". After further review, this didn't change the rejection outcome. We appealed the decision and let the case run for ten days without response other than an initial notification that it was being looked at.
Eventually, we were pressed by external deadlines - as you can see this has been dragging out for about a month now - and submitted the alternative workaround that embeds trust roots in the code, which I believes withdraws the appeal. Without the entitlement, our app has been accepted. Clearly, this is an inferior solution in terms of both maintenance and security, but for now it is our only option.
