convert_cocoa_core_data_ts_to_utc assumes its input is in seconds

`convert_cocoa_core_data_ts_to_utc` in `scripts/ilapfuncs.py` adds 978307200 seconds to its input to shift a Core Data timestamp onto the Unix epoch. It never establishes that the input is in seconds, so when a column holds a value in some other unit the addition is meaningless and the result is a plausible but wrong date.

Observed on the WhatsApp macOS chat sessions artifact. `ZWACHATSESSION.ZLASTMESSAGEDATE` holds 9 digit Cocoa seconds on 122 of 125 rows. Three rows hold a 12 digit value. Cross checking each of those chats against the newest `ZWAMESSAGE.ZMESSAGEDATE` in the same chat shows the stored instant is the right month, day and time, offset by exactly 7000 and 6000 years. So the source values are corrupt rather than in a different unit, and no conversion recovers a sensible date from them.

The three rows render as a date in the wrong century either way, so this is not a regression and nothing is currently lost. Raising it because the helper will keep producing a confident wrong date for any out of range input rather than surfacing that the value could not be read.

Worth considering: report the raw value when the shifted timestamp falls outside a plausible range for the app, so an examiner sees the stored value rather than a decoded date that cannot be right.

No fix proposed here. Filed for triage.

The function `convert_cocoa_core_data_ts_to_utc` is in `scripts/ilapfuncs.py`. First, examine its current implementation and understand how it's used, particularly for the WhatsApp macOS chat sessions artifact. Look at the data structure for `ZWACHATSESSION.ZLASTMESSAGEDATE` to see the unit of the timestamp. Then, determine a plausible date range for the app (e.g., years 2000-2030) and implement a check to flag or report raw values when the shifted timestamp falls outside that range. Run existing tests to ensure no regression.

Rédigé par le modèle d'indexation à partir du texte de l'issue.