ADOP commands were not executed in a certified manner
1) the patching is not restarted correctly when failing
adop phase=apply patches=36619106,35657401
the 1st patch failed to apply:  [EVENT] Applying patch 36619106... failed.
But the DBA ignored the failure an only restarted the 2nd patch application: 
adop phase=apply patches=35657401 abandon=yes
Because of the way the DBA gave the 2nd command, patch 36619106 failing to apply would have been completely ignored.    it is lucky that the 2nd patch also failed otherwise the DBA would have gone live on a bad patch 36619106 which would have impacted EBS data
>> When starting ADOP after a failure  the DBA ***MUST*** use the same command as the original. In this case:
adop phase=apply patches=36619106,35657401 abandon=yes restart=no
--> this would have restarted the 1st patch 36619106 which had failed to apply
.
2) the cleanup full failed status required after an abort was ignored before issuing the fs_clone
the DBA checked adop status but the INFO message got him confused that he should run fs_clone as the next step instead of focusing on the cleanup full failures.
[UNEXPECTED]Cleanup phase has failed.
adzdshowstatus.out report showed:
azebsdb2 master PREPARE SESSION ABORTED 2026/04/17 16:07:51 2026/04/17 17:18:17 1:10:26
                                 APPLY SESSION ABORTED 2026/04/17 17:20:18 2026/04/18 11:58:30 18:38:12
                                 FINALIZE SESSION ABORTED
                                 CUTOVER SESSION ABORTED
                                 CLEANUP NOT STARTED   <<< status should show as FAILED - this might be a bug.
INFORMATION: Patching cycle aborted, so fs_clone will run automatically on azebsdb2 node in prepare phase of next patching cycle.   <<< this is just informational and not to be acted upon
>> When receiving an error on an ADOP command, the error must be first addressed before proceeding further.
In this case cleanup full errors had to be fixed before trying to run fs_clone
.
3) when the patching was restarted after the error, the DBA added the option autoskip which is not supported.
adop phase=apply patches=36619106 -- applied ok by itself this time
adop phase=apply patches=35657401 -- failed
adop phase=apply patches=35657401 abandon=no restart=yes flags=autoskip <<< not supported
autoskip means whatever and whenever an error happens, ADOP should ignore it completely and go on patching anyway. This is the equivalent of applying a failed patch on the old 12.1.3 EBS and deciding to go live on the bad patching instead of restoring the filesytem.  When experiencing bad patching, Online Patching allows to "abort" a session instead of having to restore from a backup, but ignoring and bypassing errors to go live on bad patching is not a good idea.
Because the patch was applied with "autoskip", patching error were ignored by ADOP and when the DBA decided to proceed anyway, ADOP let him know in the next phase Finalize:
************************
[UNEXPECTED]The following patches failed to apply on admin node <azebsdb2> in online mode, session ID <47>
Patches: <35657401>
You can either resolve the failure and reapply the patches, or ignore the failure and allow processing to continue.
[WARNING] Only continue if you are sure it is safe to do so - continuing without first resolving the failure may lead to inconsistency and data loss.
************************
ADOP Finalize message is a direct consequence of having used the non-support autoskip option
The DBA decided to abort and correctly started a cleanup full. 
But the cleanup full is failing because it has issues restoring the EBS correctly after having used "autoskip" option during patching.
Please note that the 1st time cleanup full was used in Session 46, there was no error whatsoever.
But this time in Session 47, since the DBA used the autoskip option packages and filesystem are not in the expected configuration, cleanup full is unable to restore the system correctly and is failing
>> autoskip option is not certified and not supported in any adop patch application. 
It will create issues including ADOP management of the EBS configuration such as a failed fiinalize and cleanup full
.
Final Solution
-----------------
unfortunately with the use of the autoskip option, EBS configuration is corrupted and cannot be fixed.  
The solution is to recreate the environment UAT2 from scratch using cloning with RapidClone, then apply the patches in Online Patching session making sure to do so in a certified manner:
- if you list a few patches in the "patches= " option then you need to provide the full list again until all patches are applied correctly
- if ADOP encounters an error in a phase, do not proceed to the next phase until the error is fixed
- do not use the "autoskip" option which has never been certified or supported to apply EBS patches.
>> recreate UAT2 environment using:
KA1011 (Note 2552208.1) - Cloning Oracle E-Business Suite Release 12.2 with Multitenant Database using Rapid Clone