Problem

In the rate-limited bulk_insert_locust_w1 variant behind BF-43544, the observed standby lag is dominated by oplogSendLagMillis, while oplogFetchLagMillis, oplogWriteLagMillis, and oplogApplyLagMillis stay near zero.
Current DSC flow control uses oplogLagMillis directly as one of its signals, not the 4-way decomposition. That makes the signal too broad for this case: oplogLagMillis is directionally correct as an end-to-end staleness metric, but when send lag dominates it does not mean the standby fetch/write/apply path is slow.

Prop

Since FC has only one purpose - contain the standby so it can meet its failover SLO. Flow Control should replace current oplogLagMillis with standby fetch/write/apply lag as standby lag. 
dan.larkin-york@mongodb.com 's concern is that this can translate to unbounded data-loss risk on failover and poor w:majority latency if w:1 backlog has to be absorbed before later majority writes can commit. This concern should be addressed in other places. Thus this ticket has a dependency on that.