describe operations omit last_updated_record on RocksDB (RocksTransactionLogStore.getKeys is a TODO stub) #2091

Summary

describe_table / describe_database / describe_all silently omit last_updated_record on RocksDB storage — a regression vs LMDB, where the field is populated from the audit store.

Cause

dataLayer/schemaDescribe.ts computes the field from the audit store's newest key:

for (let key of auditStore.getKeys({ reverse: true, limit: 1 })) {
	tableResult.last_updated_record = key[0];
}

but RocksTransactionLogStore.getKeys() is an unimplemented stub:

getKeys(_options?: any) {
	return []; // TODO: implement this
}

and the indices.__updatedtime__ fallback doesn't exist on these tables, so the field is simply never set.

Impact

• Users of the describe operations lose last-update visibility on RocksDB deployments.
• Downstream, harper-pro's clone_node derived its sync-verification targets from this field; all-zero targets made clone sync verification vacuous (clone marks itself Available mid-copy) — see Clone sync monitor is vacuous on RocksDB: clone marks itself Available mid-copy (targets all 0) harper-pro#655, which fixes the clone side independently of this issue.

Implementation notes

There is currently no cheap tail read on the transaction log: rocksdb-js TransactionLog only exposes forward query() (_findPosition is a forward running-maxima index; getStats().lastCommittedPosition is a byte position with no timestamp). A small rocksdb-js API — e.g. getLastEntry() returning the newest committed entry (or just its timestamp) using the already-tracked last-committed position — would let RocksTransactionLogStore.getKeys({ reverse: true, limit: 1 }) be implemented per the existing TODO, restoring the describe field.