v1.4.4

Fixes

Batch writes never recorded day-bitmap membership (#5). Engine::insertBatch recorded membership from request timestamps the memory store had already moved out, so the loop was a no-op on every batch write since 1.4.1. Established series only had membership for the day their first-batch MetadataOp announced (plus whatever the startup repair restored), and time-scoped queries whose range started after that returned nothing with the data present. In production the discoverable builtIn.node.stats series in one project decayed 194 → 161 → 111 → 2 → 1 → 0 over the six days after the 1.4.3 restart. Membership is now recorded before the data write. Regression test goes through the real batch path.

One repair on upgrade, even after a clean stop (#5). The clean-shutdown marker now carries a recorder generation ("2"); open() treats any other value as unclean and runs the day-bitmap repair once. Expect Repaired day bitmaps: … on every shard on the first boot of 1.4.4; later restarts skip it as before.

Decode failures name the block (#6). A block decode error now carries [block offset=… size=… count=… time=a..b hdr.count=… hdr.tsBytes=… skip=… n=… valueBytes=…] ahead of [tsm <file>], so descriptor-vs-bytes can be told apart from the log line alone. readSingleBlockImpl also copies the block descriptor before its DMA suspension instead of re-reading it through the caller's reference afterwards.

Upgrade notes

• First boot repairs day bitmaps for the last index.day_bitmap_rebuild_window_days (32) days from TSM bounds — ~4 s per shard at ~75k series. The service is not ready until it finishes.
• No on-disk format change. 1.4.3 remains a valid rollback target (it will run the repair on its own first boot because the marker generation differs).