fix(tracker): make cleanup cron observable + robust (#2)

[mageaustralia]

Fixes #2.

What

The source-module cleanupOldRecords() cron job (maho_datasynctracker_cleanup, runs 0 3 * * 0) was reported as not firing / failing silently, with old synced rows accumulating.

The plumbing is all present and correct (cron wired in config.xml, method exists, synced_at column exists and is set by the destination's markAsSynced()). The real gap is observability plus one latent data edge case:

1. Log at entry (with the cutoff), so every run is visible in datasync.log even when it deletes 0 rows or errors before completing. Previously the only log line was on success-exit, so a job that never ran or failed early left no trace, which is exactly the reported symptom.
2. Log failures to datasync.log too (not just the exception log), so "cleanup isn't working" is diagnosable from a single file.
3. created_at fallback when synced_at IS NULL: a synced row should always carry synced_at, but any path that set sync_completed = 1 without it would never match the delete (NULL < date is never true) and would accumulate forever. The delete now also catches those.

Why not a code-presence fix

This issue was originally filed against an assumption the cron/method might be missing. They aren't, so this hardens what exists rather than re-adding it. The remaining "is the host cron actually running this job" check is operational (verify cron_schedule for maho_datasynctracker_cleanup on the live store) and can't be fixed in code; the entry-log added here makes that verifiable.

Notes

• Source-side OpenMage/Magento 1 module, so Varien_* / Zend_Log are intentional here (this is not Maho).
• No schema change. php -l clean.

Test plan

• On the live source store, run the job manually (or wait for the schedule) and confirm a DataSyncTracker cleanup: starting... line appears in var/log/datasync.log, followed by a deleted N old synced records line.
• Verify cron_schedule has maho_datasynctracker_cleanup rows transitioning to success.
• Seed a row with sync_completed=1, synced_at=NULL, created_at < 30d ago and confirm it is now removed.