Datalake validation fixtures are built from the wall clock, not the declared execution date

ingestion/tests/unit/observability/data_quality/test_validations_datalake.py builds its fixture rows at module import time from the wall clock:

EXECUTION_DATE = datetime.strptime("2021-07-03", "%Y-%m-%d")   # line 39
...
DL_DATA = (
    [... "John Doe", "johnny b goode", 30, datetime.utcnow() - timedelta(days=1), ...],
    ...
)

Eight rows, each datetime.utcnow() - timedelta(days=N) — while the test case handed to the validator declares execution_date=EXECUTION_DATE.timestamp(), a fixed 2021 date. The fixture data and the declared execution date are therefore about five years apart, and the gap changes on every run.

Why it matters

Nothing in the file is deterministic across runs, and the offset between "now" and the declared execution date drifts continuously. Any assertion added later that reads inserted_date, or any validator change that starts comparing row timestamps against execution_date, inherits a wall-clock dependency that will fail intermittently — most visibly around a UTC day boundary, where utcnow() at import and the assertion can land on different days.

Being precise about today's blast radius: no test in the file currently asserts on inserted_date — it appears only in the DataFrame column list — so the suite is not failing today and this is hardening rather than a live bug fix.

How we know it is fixed

• The fixture derives from EXECUTION_DATE instead of datetime.utcnow(), so the row timestamps sit at a fixed offset from the execution date the test declares.
• The parametrized test runs under @freeze_time(EXECUTION_DATE), so anything that reads the clock during validation sees the same instant the data was built around.
• All 57 cases pass, and the file no longer references datetime.utcnow().
• freezegun is already declared in ingestion/setup.py's test extras.