That's not possible because the recovery is triggered at the same time as the alert is triggered, not after it; so the alert doesn't exist yet when the recovery starts and therefore it can't access the alert properties, at least not in the form of a SCOM workflow variable.
One workaround would be to use a Get-SCOMAlert cmdlet in the recovery with some mechanism to make sure it gets the details of the proper alert, but that would make it much heavier.