Answer
Directly updating the very record a Custom Event is triggered by its own creation isn't reliably achievable this way — the record isn't fully committed/addressable yet at the point the creation-triggered event fires, which is why the update lands on an unrelated (previous) record instead. Two workable alternatives: have the custom event trigger a background job that performs the update slightly after creation completes, or configure the custom event to fire on a different, subsequent action/event rather than the creation event itself, so the target record is fully committed by the time the update runs.