refactor: separate activity occurrence dates from creation dates

[anonymoususer72041]

This PR separates the functional occurrence timestamp of activity records from their technical creation timestamp.

PR #758 made it possible to log activities with a manual date and time, but the manually selected activity timestamp was stored in activity.date_created. That made the activity timeline behave as intended, but it also changed the meaning of date_created: instead of always representing when the database row was created, it could represent when the activity occurred.

This PR adds a dedicated activity.date_occurred column and backfills it from the existing date_created values so that existing activity timelines keep their current ordering and displayed timestamps after migration.

Manual activity dates are now stored in date_occurred, while date_created is always set to NOW() when a new activity row is inserted. Editing an activity date also updates date_occurred instead of overwriting date_created.

Activity timelines, activity grids, date filters, activity statistics, and latest-activity lookups now use date_occurred as the functional activity timestamp. Existing output aliases such as dateCreated, dateCreatedSort, and lastActivity are intentionally kept unchanged to avoid unnecessary template and JavaScript changes.

This restores date_created as the technical record creation timestamp while preserving the user-facing behavior introduced by manual activity dates.