feat(sociallikes3): migrate persisted timestamps to epoch millis

[marzipan99]

Summary

• centralize persisted SocialLikes3 timestamps as epoch-millisecond strings with legacy dual-read support for the historical New York, JST, and UTC eras
• add a versioned, checksummed SQLite migration for builds.created_at, builds.deleted_at, publicity_history.timestamp, and sl_event_log.occurred_at
• keep populated-database conversion out of plugin startup and fail closed until an operator performs the stopped-server migration
• fix the remaining persisted FollowBuild / SLtp timestamps and make the rank-up cutoff explicitly UTC
• include a standalone migration entry point and manual backup / candidate-DB / verify / rollback helper under plugins/SocialLikes3/tools/

This PR no longer changes GitHub Actions, Nix image construction, CDKTF, or ordinary production deployment behavior. It does not add a production deployment gate or request a CODEOWNER review.

Manual cutover

Merging this PR does not modify the production database or stop the server. The existing deployment workflow is left unchanged.

For the one-time production cutover, an operator will:

1. wait for the merged commit and its SocialLikes3 JAR/image to finish building, without deploying it yet
2. confirm zero online players, prevent new connections, run save-all flush, and stop oyasai-minecraft-main
3. provide the new SocialLikes3.jar as SL3_MIGRATOR_JAR
4. run release-timestamps.sh prepare, which performs preflight checks, creates a full plugin-data backup and candidate DB, then runs transactional dry-run, apply, and verification on the candidate
5. run release-timestamps.sh activate to swap in the verified candidate DB
6. run the repository's existing production deployment process for the merged commit
7. verify container health, /sldataop timestamp-health, migration state, and startup logs before accepting traffic

If a cutover step fails, the operator keeps traffic closed and runs release-timestamps.sh rollback before restoring the previous application release.

Existing populated databases are never rewritten during plugin startup. A genuinely empty new database may initialize the schema marker automatically. YAML readers remain backward compatible and rewrite touched values in epoch form.

The existing VARCHAR columns are intentionally retained for this compatibility release; their values become 13-digit epoch milliseconds. A future clean-schema revision can change the in-memory model to Instant and the SQLite affinity to INTEGER independently.

Validation

• nix fmt
• ./gradlew :plugins:SocialLikes3:build
• nix flake check -L --max-jobs 2 --cores 2
• fat-JAR fixture: preflight -> dry-run -> apply -> activate -> verify -> rollback
• malformed-value rollback, idempotency, empty-database initialization, and historical-zone conversion tests

Production evidence used

The production SQLite database was inspected read-only before implementation: integrity check passed, user_version was 0, and all four target columns still contained legacy ISO local timestamps. No production files, containers, or database rows were changed while preparing this PR.

Generated with Codex.

[shunueda]

Migrationをインフラの一環として管理するのは無理。マニュアルでMigrationしよう

直前のコミットにより解消