Audit log CacheHitRatio is always 100% for multi-node queries in shared-data mode

[starrocks-xupeng]

Steps to reproduce the behavior

1. Shared-data cluster with at least 2 CNs.
2. Create a table whose tablets spread across both CNs and load some data.
3. Make the data cold on one CN (e.g. UPDATE information_schema.be_configs SET value='0' WHERE name='datacache_disk_size' on that CN), keep it warm on the other.
4. Run a full scan query whose result sink lands on the warm CN, then check CacheHitRatio in fe.audit.log.

Expected behavior

The audit log reports the real query-wide data cache hit ratio, e.g. CacheHitRatio=50.3%, aggregating the read counters from every CN that scanned.

Actual behavior

The audit log reports the constant fallback CacheHitRatio=100% for virtually every multi-node query, no matter how much data was read from remote storage. On a production cluster a 12.8s query that read 4.75 GB from S3 (profile shows an IO-count hit ratio of 95.1%) was logged as 100%.

Root cause

CacheHitRatio is computed on the FE from the read_local_cnt / read_remote_cnt counters shipped from BEs. Only QueryContext::final_query_statistic() includes these counters; intermediate_query_statistic() — the delta statistics that non-final-sink BEs piggyback on exchange traffic — does not carry them. Since the final-sink BE usually runs no scan, the scan-side counters are lost and AuditEvent.calculateCacheHitRatio() falls back to "100%" (readLocalCnt + readRemoteCnt == 0).

StarRocks version

main / 4.1 / 4.0 (every version carrying the audit cache hit ratio feature)