Please check this blog post if it helps...
https://jsreport.net/blog/barcode-in-report

The jsreport-client is server side nodejs package.

If you want to call the jsreport server from the browser, you should check the browser client here
https://jsreport.net/learn/browser-client

Please try to create a minimal github repo and replicate the problem there so I can take a look.

Here is the code to read a file in the script and put it to the report result.

const fs = require('fs')
const path = require('path')
function afterRender(req, res) {
    res.content = fs.readFileSync(path.join(__appDirectory, 'myfile.txt'))
}

Did you check this tutorial?
https://jsreport.net/learn/periodical-report-sending-through-email

I think you over-complicate it with the extra handlebars when jsreport has it wired already and you can just email the outputs from the afterRender script.

Could there be a problem when two separate parameters are using childTemplateSerializeData?

I don't see any problem with that.

Or does childTemplateSerialize data leak in some way that prohibits two consecutive renders?

Also not aware of that.

I tried it here and it seems to work as expected
https://playground.jsreport.net/w/anon/eW6NUT1e

It would be great if you can send me an updated export or guide me on how to replicate the problem.

So finally, I found the problem. Here is some technical background if interested in what is changed in the 2.10.0.
https://github.com/jsreport/jsreport/issues/725

What's happening here is that we aren't able to properly parse the hidden marks you add to the pdf using pdfAddPageItem helper.
For some reason, the mozila pdfjs skips letters f and i when rendered using your fonts.
The current solution is to add an explicit font to our hidden marks. This is fortunately very easy. Just add this to your main template styles.

 .jsreport-pdf-utils-page-item {
   font-family: Helvetica
}

.jsreport-pdf-utils-page-group {
  font-family: Helvetica
}

I tried to render several hundred of reports with 10x in parallel and didn't see the error occurring again.
Please try it out and let me know.
We will then consider to always use the explicit font family.

Q2: Is req.data really serialised? If that were the case I wouldn't be able to use the i18n instance since functions cannot be serialised.
Q3: Why does it seem to be serialised in dedicated-process? (according to the error)

Yes, dedicated-process strategy means that it evaluates javascript in extra process. This means it needs to serialize req.data when communicating with it. The script and helper calls are using different process. This means they can share just plain objects.

Q4: Why does my report often crash on second render when using in-process? The answer might be that my method of setting an i18n instance to req.data.i18n is flawed.

This should work. Because the instance is shared in the same process.
I tried something like this without problems. It works consistently with in-process strategy. You would probably need to isolate the problem.

async function beforeRender(req, res) {
    const i18next = req.data.i18next = require('i18next').createInstance()
    await i18next.init({
        lng: 'en',
        debug: true,
        resources: {
            en: {
            translation: {
                "key": "hello world"
            }
            }
        }
    })   
}

Q1, the obvious question: How to safely marshall an i81n instance to my helper functions?

I think there is some kind of hacky way how to reconstruct the i81n instance from the serialized plain object. However, what looks more straightforward to me, is construct the i81n instance in the helpers section. This can be done because since jsreport 2.8.0 you can write asynchronous helpers.

 const i18next = require('i18next').createInstance()
 
 const initPromise = i18next.init({
        lng: 'en',
        debug: true,
        resources: {
            en: {
            translation: {
                "key": "hello world"
            }
            }
        }
    })   

async function myHelper() {
    await initPromise
    return i18next.t('key')
}

Then call the helper in common way {{myHelper}}

Could you to email me the export zip so I can try to replicate it? Thank you

The error says you are trying to read the directory where the file is expected.
Please share your code in the afterRender.