Thank you for sharing this. As soon as I have some time I will update the documentation.

but when I scale-out or git push, some instance randomly dies. After looking at the log it shows there's a concurrency issue during startup on file fs.lock

That is likely because of slow file system.
The error comes from the lock library we use to make sure we don't access the file system in parallel.
https://github.com/npm/lockfile
The same error is described also here
https://github.com/npm/lockfile/issues/26

The following jsreport configs with defaults are used as options for the locking library.

extensions_fsStore_persistence_lock_stale=5000 extensions_fsStore_persistence_lock_retries=100 extensions_fsStore_persistence_lock_retryWait=100

You can see we use quite many retries to allow long operations. It looks like the file share has really bad latency in your case. You may still try to increase the retires or change stale to see if it helps.

Q: I'm wondering if jsreport can have an option that just take a folder as read-only template-store without creating additional files and monitoring over that folder

I'm afraid this isn't supported. The common solution as you observed is to map the data to some tmp or tmpfs

Q: I'm thinking if it's possible to have a callback mechanism from jsreport so I don't need to keep the mapping from the random name to my callback

The callback isn't implemented in the reports extension. I've added it to the backlog.
https://github.com/jsreport/jsreport/issues/1091
If you have any suggestions about how the callback request should look like and how it should be configured, please add it to github issue.

I've seen somewhere here a guy solving this using jsreport script and after render hook.
https://jsreport.net/learn/scripts

Q: is it safe to use below request? I found that from jsreport repository but it's not mentioned in doco

Yes.