v3.4.136

Fix revoked entitlement blocking recreation when a refund is reversed.

create_entitlements_for_recipient() unique-keys rows by order_item_id,
Drive resource, and recipient email. The automatic order-status flow
called it with reuse_revoked=false, so a leftover revoked row for that
exact tuple was never reactivated — but a plain INSERT for the same
tuple always collides with that unique key regardless of the flag, so
entitlement creation failed every time and the recipient never got a
fresh entitlement.

This surfaces when a refund that revoked a recipient's access is later
reversed (effective quantity restored) and the order re-enters
processing/completed: entitlement creation fires again, hits the
revoked row, and silently fails for that recipient going forward.
Admins had a manual workaround via the reassign-email flow, but the
automatic path had no recovery.

Fixed by reactivating the exact-tuple revoked row from the automatic
order-status path too, matching the admin reassignment flow — since
reactivating it is required by the unique key, not optional.