[illia-sapryga]

A CRM export can hash identifiers before it writes the file, so raw values never reach disk. draft_upload_enhanced_conversions_for_leads assumes raw values. A digest in the Email column has no @, so it's dropped as "not an address". In the name columns it gets hashed a second time. Either way the row can't match, and only the email and phone cases say anything.

A cell holding a full 64-character SHA-256 hex digest is now used as it is, lowercased. This is per cell, so a file can mix raw and hashed columns, and raw cells are normalized and hashed as before.

I checked the preview counts against a file with digests. rows_with_email, rows_with_phone and rows_with_address come out the same as for the equivalent raw file, and digests aren't reported as a broken phone or email. Two things needed adding:

• An export that hashes every cell turns a blank one into the digest of the empty string. That would have counted as an identifier and been uploaded, so it now counts as the blank cell it was. A row with nothing else is skipped like any row with no identifier.
• A digest can't be checked for normalization, and a wrongly normalized value matches nobody without any error. When a file has digests, the preview adds rows_with_prehashed_identifiers and a match_warnings line saying so, with the first affected rows.

What it does not do: it doesn't add an option or a new tool, and it doesn't verify digests in any way beyond their shape. Files without digests produce the same preview as before. The sample rows still show sha256:set and not the hash.

Tested with the full suite plus TestPrehashedEcIdentifiers, including a run through confirm_and_apply(dry_run=True) with the real validate-only wrapper and a fake upload service, which asserts the digests arrive unchanged in hashed_email and hashed_phone_number. I have not run this code against a live account, and match rates for prehashed uploads are untested.