Some thoughts:
Install it outside the rootvg so not in /usr or /opt
Don't bury it deep in a path. Something like /[application]/[instance]/irissys for example
Data in a separate volume group to enable snapshots and the external freeze.
Journals in a separate volume group to enable snapshots and the external freeze.
Keep instance names unique unless it is a failover member or DR async

Look at Storage Planning
 

You could optimize this:

If F1 > 0 and F2 > 0

F1 > F2 ; positive

F1 < F2 ; negative

no need do the subtraction.

Sounds much the same as these threads:

For IP address transfer/takeover to work the network has to be the same. Other clustering solutions work like this.

Planning a Mirror Virtual IP (VIP)

If by fake you mean not the normal OS level clustering solution that is true. It is an app specific solution.

If the cost of the 2x storage is an issue maybe a deduplicating SAN would reduce the cost at the added risk not having redundant storage.

Have you tried using ^MIRROR?

Remove Mirrored Databases from a Mirror

If you do performance testing the storage is going to be allocated either anyway so might as well do it upfront.

This looks like what you want Using the ^MIRROR Routine

I am interested in InterSystems IRIS: What’s New, What’s Next and InterSystems Data Platforms Roadmap: Leading in the Data and AI-Driven Era.

I don't see that in the documentation - final classmethod CatchupDB(DBList As %String, JournalLocation As %String = "", ByRef DBErrList As %String) as %Integer

A low impact way to do this would be take a SAN snapshot of production and mount the snapshot in test.

Intersystems discusses this in External Backup.

The easy way to retain some database is mount them from a different set of disks/filesystem.

If you have a DR mirror but not a SAN you could just shutdown the DR mirror and do a cold backup.

If test is a separate mirror the whole test mirror will have to be refreshed due to mirror headers. If test is part of the same mirror as production then the data is already there.

In two really key ways multi-volumes datasets don't allow you to escape limits you might want to escape.
The max size of a multi-volume dataset is the same as a single file - 34 TB (33553904 MB) for 8K database. Intersystems is working to increase the max size.
An integrity check also treats it as if it was a single file. This is only going to be more of an issue as the max size increses.

Truncate can only remove free space from the end of the file.
Compact is asking how much free space do you want at the end of the file.
The free space is likely not evenly distributed.
I mostly used the ^DATABASE utility.

It looks like you are missing the kill to cleanup.

kill ^IRIS.TempIntegrityOutput(+$job)

Something to know is you can pass a routine to IRIS but not a set.  Look at the iris terminal options here.

As a guess the shell is interpreting $job rather than passing it to IRIS.

try this

echo 'set sc=$$CheckList^Integrity(,,,,5) do Display^Integrity() kill ^IRIS.TempIntegrityOutput(+$job)' | iris session [INSTANCE] -U %sys

one issue with this approach is you need to get the same IRIS session that the integrity check ran in.

An instance name is not guarantied to be unique.
hostname/ip + instance is.
For example the instance name of our failover primary and backup is the same they are just on different hosts.
We use DNS name not IP addresses though so we have DNS/instance for SystemName.

Mirroring Configurations within a Single Data Center, Computer Room, or Campus

I would ask your vendor what they develop on so you don't have to listen to an excuse around a support issue.