[BUG] Instance last heartbeat time is never persisted or restored #7723

Current behavior

InstanceInfoServiceImpl.createOrUpdate assigns lastHeartBeatTime on the Java entity for updates, but the instance mapper's column list, result map, insert and update statements contain no heartbeat timestamp. The reviewed initialization schemas also lack this column. The create conversion does not copy the value either. Database reads therefore produce the Java default 0 for a primitive long.

The instance list overlays this with a live local map, masking the omission. Detail queries read the database, and InstanceCheckService.fetchInstanceData restores database values on startup/master election. A restored record consequently has no durable last-seen observation, and the checker can age it from epoch zero if no new report arrives. Do not use date_updated as a substitute: periodic persistence updates that field independently of receiving a heartbeat.

Source evidence

• Mapper and column/result definitions
• Service assigns the value before calling mapper
• Create conversion omits heartbeat
• Startup restore

A local XML inspection confirmed that Base_Column_List, BaseResultMap, insert and updateById omit this field. No database/runtime reproduction was executed during issue preparation.

Acceptance criteria

• Define durable last-seen semantics and persist/read the heartbeat observation consistently through create, update, list and detail paths.
• Add initialization/upgrade changes for supported database dialects and explicit handling of historical rows with no observation.
• Mapper integration tests round-trip a fixed nonzero timestamp through insert and update; mock-only service tests are insufficient.
• Test Admin restart/master handover, with and without a subsequent heartbeat; unknown/stale observations are represented explicitly rather than fabricated as fresh.
• Preserve namespace identity and distinguish last report time from last persistence time.

Related: #7697 concerns missing local-map entries; #7718 concerns readiness; neither repairs the persistence contract.

Database verification update (2026-10-17)

Reproduced using the H2 instance-table DDL and MyBatis XML mapper from 66d7d954ca37d651a5ad916f988a8081157a7ab4, plus recompiled current InstanceInfoServiceImpl, entity, VO and mapper interface. This probe used a real H2 database and MyBatis sessions, not a mocked mapper.

A nonzero heartbeat (1700000000000) was supplied on create; the database-backed entity and detail service read 0. Updating the heartbeat to 1700000009999 still read 0. Assertions confirmed both insert and update round-trip omission.

No production source was modified. Other database dialects and Admin restart were not executed; this verifies the persistence omission underlying those scenarios.