Yes, if you gave them the data in the original PCS, it would be off since it has a different origin than the new PCS.
The next problem is, what vertical system were the GCPs in? Orthometric or Ellipsoid. If ellipsoid, then the data will be in ellipsoid. If they were expecting an orthometric then it would be incorrect.
Next, checkpoints are a must in my opinion, and I am surprised the surveyors did not incorporate them along with a center GCP. I am not sure of what will be done with the data, but if you are giving an output of contours I would assume they want vertical.
102629 seems to be supported in Drone Deploy.
If processing with the new 102629 works horizontally, you can use Drone Deploy to perform the Elevation Calibration. Use the elevation from a GCP to set the elevation for the map. This calibration should also apply to the outputted contours and DEM. But this goes back to if the elevations on the GCPs are ellipsoid or orthometric. If ellipsoid, use this tool to gain the undulation and then use this formula to obtain the orthometric elevation H=h-N (h is the ellipsoid value of the GCP and N is the undulation) where you take the ellipsoid elevation of the GCP and then subtract the undulation you get from this tool:
404 Error: Page Not Found
Your project seems like a nightmare for the client, surveyors, and yourself. They should see that the two EPSG codes have different origins and when giving the wrong code would have a large shift.
In the future request the GCPs be in a more friendly PCS based on NAD83 (2011) and ask them to specify if the elevations are in and need to be in orthometric or ellipsoid.
But in some cases, the data will be a local coordinate system, and Agisoft Metashape or Pix4D would be a better software solution.
Drone Deploy may have some incredible tools but starts to lose some luster when flexibility comes into play.
