fix: enable timely stats update to avoid large row count estimation deviation (#23692)

After the stats refactoring, when multiple secondary indexes are created concurrently, the planner observes a smaller `Stats.OutCnt` because global stats were not updated in time on data object (block) changes. The upgrade-to-table-lock condition (`Stats.OutCnt >= MaxRowLockCount`) is then never reached, so the system keeps acquiring row locks and can accumulate ~100M row locks causing OOM (see issue #23689).

This change treats data object logtail entries (`api.Entry_DataObject`) as meta-changing in `processLogtail`, in addition to existing meta entries. When blocks/data objects change, they are counted as meta changes and can trigger stats refresh (subject to existing rate limiting in `shouldEnqueueUpdate`). Stats then reflect table size more timely and row count estimation deviation is reduced, so the planner can correctly upgrade to table lock and avoid excessive row locks.

Approved by: @gouhongshen

Author: aptend

pkg/vm/engine/disttae/stats.go

@@ -28,6 +28,7 @@ import (
 	"github.com/matrixorigin/matrixone/pkg/fileservice"
 	"github.com/matrixorigin/matrixone/pkg/logutil"
 	"github.com/matrixorigin/matrixone/pkg/objectio"
+	"github.com/matrixorigin/matrixone/pkg/pb/api"
 	"github.com/matrixorigin/matrixone/pkg/pb/gossip"
 	"github.com/matrixorigin/matrixone/pkg/pb/logtail"
 	"github.com/matrixorigin/matrixone/pkg/pb/query"
@@ -486,7 +487,7 @@ func (gs *GlobalStats) processLogtail(ctx context.Context, tail *logtail.TableLo
 	// Count meta changes from logtail by checking batch length
 	metaChanges := 0
 	for i := range tail.Commands {
-		if logtailreplay.IsMetaEntry(tail.Commands[i].TableName) {
+		if cmd := tail.Commands[i]; cmd.EntryType == api.Entry_DataObject || logtailreplay.IsMetaEntry(tail.Commands[i].TableName) {
 			if tail.Commands[i].Bat != nil && len(tail.Commands[i].Bat.Vecs) > 0 {
 				metaChanges += int(tail.Commands[i].Bat.Vecs[0].Len)
 			}