Argo provides an incredible workflow engine for Kubernetes. It is _more_ than enough to handle the workloads of running Fabric CLI binaries - you are on a solid course for workflow automation!
Regarding the context, it's possible / likely that PIVT is setting the core.yaml in a way that is different than the test network's use of Compose. Perhaps there are some environmental differences that are getting flushed out by calling the peer CLI in a new context. The ledger interaction with the final phase of the commit is different than the install / approve - I don't think it's actually attempting a consensus across orgs until the final commit step in the chaincode lifecycle.
Maybe - one last plug - try the new fabric-operator and fabric-k8s-builder lifecycle? At least to see if it reduces the need for workflow automation, or what steps would be necessary to reach parity with the PIVT syntax? BTW there are some efforts underway by the community to assemble a test and performance benchmarking environment, based in part on a workflow engine (Argo!) or scripted automation. Would welcome your feedback on the general approach for CI and deployment automation with Argo - this is a great step forward. Please keep the mailing list posted on your progress, or drop a note over in the #fabric-kubernetes channel at Discord when you have finally arm-wrestled Fabric into submission.