This approach is unlikely to provide you with useful information. The surfaces and orthomosaics built by Metashape would have both exploited the positional data of the drone at the time of image capture. Differences in GNSS signals at the time of image capture would introduce enough uncertainty in the two different outputs such that they do not align as you have stated. The lack of ground control points for the reconstructions ensures the resulting products only use the drone GNSS and IMU data. As you likely know, the x, y, and (especially) z values from consumer grade GNSS units have an uncertainty expressed in meters from the actual location ensuring that your surface will not align to the same vertical and horizontal datums - thus your calculations will never be 'accurate'.
Still, if you want to proceed I would suggest that you:
- Georeference one of the orthomosaics to the other.
- Save the resulting newly georeferenced orthomosaic as a TIFF with a world file (not a GeoTiff).
- Save the matching surface to a TIFF with a world file (not GeoTiffs).
- Delete the world file for that surface.
- Make a copy of the orthomosaic world file in the same directory as the surface Tiff but name that world files the same name as the surfaces.
This will apply the same shift to the surface as the newly georeferenced ortho and force the data to align.
Do your raster math with the understanding that the Z values will not match the same vertical datum because of GNSS error at the time of image capture.
EDIT: In addition to my answer above I wonder if your area of interest has existing imagery, LiDAR, and possibly roads? If so, create some faux GCPs using unaltered portions of roads, some road paintings like crosswalks or parking lines. Create GCPs based on these locations. Reprocess both flight data with these faux GCPs to align. Do your raster math.