Event details
The default DB will not change at all by actions done by the Secure Boot updates. If there is a firmware update, it may include them (or provide an option to enable them). If not, live with the fact you will need to run securebootrecovery whenever you reset your firmware variables.
With "Broadcom documented process" you refer to article 423919 in their knowledge base, specifically to use UEFI setup to manually change PK to the one with Thumbprint 3d86...48b5? There should be a signed update available for that one (according to secureboot_objects), but when you went that far and took precautions like about TPM before, why not just repeat the process and enroll KEK available in the same way?
https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/KEK/Certificates/microsoft%20corporation%20kek%202k%20ca%202023.der
Yes, although the Broadcom documentation indicate KEK update as an optional step, but it is recommended to enroll KEK also. At least two VM encountered similar secure boot update failure when KEK update is not enrolled. And the registry key may need to reset to the original 0x5944 to restart the entire progress if it still stucks at 0x4004 after the KEK update.