dolt_history_<table> returns no rows for newly-added table after merge/cherrypick/rebase atop structural change

[timsehn]

Summary

dolt_history_u returns 0 rows on both doltlite and Dolt after the following sequence — surfaced by the new empty-both guard in PR #838 (oracle suite).

Repro

CREATE TABLE t(id INTEGER PRIMARY KEY, v TEXT);
INSERT INTO t VALUES (1, 'base');
SELECT dolt_add('-A'); SELECT dolt_commit('-m', 'c1');
SELECT dolt_checkout('-b', 'feat');
CREATE TABLE u(a INTEGER, b INTEGER, v TEXT, PRIMARY KEY(a, b));
INSERT INTO u VALUES (1, 1, 'one');
SELECT dolt_add('-A'); SELECT dolt_commit('-m', 'feat_add_u');
SELECT dolt_checkout('main');
CREATE TABLE t_new(id INTEGER PRIMARY KEY, v TEXT CHECK (length(v) > 0));
INSERT INTO t_new SELECT * FROM t;
DROP TABLE t;
ALTER TABLE t_new RENAME TO t;
SELECT dolt_add('-A'); SELECT dolt_commit('-m', 'main_check');
SELECT dolt_merge('feat');

-- Both engines: 0 rows.
SELECT CONCAT('R|', a, '|', b, '|', v, '|', message)
FROM dolt_history_u ORDER BY a, b, message;

Same outcome for dolt_cherry_pick('feat') and dolt_rebase('main') variants.

Naïvely the merge brings u into main with feat_add_u's contents — dolt_history_u should at minimum show that commit row. Both engines agreeing on empty suggests one of:

• Known limitation: dolt_history_<table> doesn't track tables added via merge of a feature branch atop a structural change on the receiver side.
• Real bug shared by both engines.
• Some interaction with the multi-column PK on u plus the parallel structural change to t.

Status

Currently marked EXPECT_EMPTY in test/vc_oracle_diff_multi_pk_test.sh (Group K) so the oracle suite's empty-both guard doesn't block CI on a parity-preserving gap. If the investigation determines dolt_history_u should return rows for this case, swap EXPECT_EMPTY back to the standard assertion and fix the engine(s).

Affected tests

• k_merge_replay_multi_pk_history
• k_cherrypick_replay_multi_pk_history
• k_rebase_replay_multi_pk_history