Fix duplicate MAR issue in Toast connector for applied tax records

[frederikkofoed]

Problem
The orders_check_selection_applied_tax table generates a random UUID for records that lack a guid from the Toast API. Since this random ID is part of the primary key, every sync treats the same record as a new unique row, causing massively inflated Monthly Active Row (MAR) counts in Fivetran.

Solution
Changed to use a deterministic hash based on orders_check_selection_id and taxRate_id, ensuring the same record gets the same ID across syncs.

Changes

• Added import hashlib (standard library, already used in other connectors in this repo)
• Replaced uuid.uuid4() with an MD5 hash of parent_id + tax_rate_id in process_child() for orders_check_selection_applied_tax records

[cla-assistant]

All committers have signed the CLA.