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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.