You can leverage Engine.get/setLatencySamples to do this.

I discussed it here, and I believe someone developed an automated process for it on the forum elsewhere (I can't find the link, or perhaps I am going mad)....

I'm not terribly confident the HISE CLI/MCP could handle this, but you could direct an agent to load each network, one at a time, into a HardcodedMasterFx. Each time get it to recompile with:

Console.print(Engine.getLatencySamples);

Collect all those values, then anytime that network is loaded in, use Engine.setlatencySamples to update the host. In my experience these two functions will work both when the plugin is loaded, and during real-time processing (presumably at blockrate).

Likewise you could turn an Agent onto the source code and read the DSP pieces (as griffinboy suggested), but in a complex network, done for all 133 FX, I picture that leading to more errors long-term.

*Note: I've never tested this method thoroughly enough. Possibly some hosts are not going to support dynamic changes to the latency reported *

I was under the impression that Hise has a Hisescript way to probe latency?
And so you could measure it whenever you make a change to the FX stack. But maybe I was mistaken.

If I'm honest with you, in this situation, this is the kind of task I would be lazy and let an AI agent handle.
Although I know already that you might not have something like that set up.
But if it were me solving it, I would be tempted to be lazy and brute force it, use the REST API and Codex, and have it send timed impulses through the empty chain, and then through each FX once loaded individually. That then becomes the lookup table of all the latencies. Do it for different sample rates to find the ones that scale with sample rate. Since its a serial chain, you can basically just add together the latency that each processor give you. I would also entirely discard any latency that is non-linear / different for different frequencies, for individual effects.
I would discard the entire value for that effect, because those are likely nonlinear-phase / group delay latencies and it will actually have a worse sounding phasing if you compensate for those.

That's the lazy route. It's pretty wasteful.
And I suppose you could actually do this by hand too, using the Hise latency finding tool, and write the LUT yourself.

But personally I always keep track of the latency of my own DSP while I'm developing it, so it's never a mystery. But I can only do that because I only use my own C++ DSP in Hise.

An alternative is that you could read through the source code of whatever DSP pieces you are using and find all the delays though (it will mostly be explicit delay lines for lookahead, feedback stabilization, and things like Linear phase oversampling (dont try to compensate nonlinear phase oversampling), and FIR filters, FFT) those all give measurable latency.

But yeah, if there is a Hisescript API for measuring latency, I would assume that is the thing to use! You could even build a LUT using Hisescript and no C++, if that feature exists.