de0u
The device downloads a new release, sets things up for Recovery to do the A/B swap, and then reboots into Recovery.
The update process doesn't involve recovery in any way. The update system downloads, verifies, installs, validates and finalizes the update in the background. The next boot loads the new OS version.
Recovery does the same checks as it would for an OTA sideload, e.g., the new OS is signed with the correct key and isn't a version downgrade. If the new OS passes, Recovery does the slot swap, and boots the new OS.
Recovery isn't involved.
The new OS waits to be unlocked, then offers the secure element new firmware.
Secure element firmware is updated on each boot after Owner profile unlock, not only after updates. It doesn't know if it succeeded in the previous boot.
The secure element validates the new firmware before installing it.
It checks the signature and version, and only permits this after Owner user authenticates successfully.
If that is right, then the insider attack protection that is provided is that Google could prepare a malicious OS update containing malicious secure-element firmware, both with good signatures and version numbers, and that OTA image could be loaded onto the device, but the new secure-element firmware wouldn't be accepted by the secure element without the unlock code.
The purpose of the feature is preventing a bypass for the decryption via an insider signing a compromised release with the HSM such as a state coercing the company to do it or a group of employees doing it.