At this point I lean to not do this, and instead live with possibly sending duplicate data after restarts. We already have the past batcher tx check at startup, so this is a super rare case to hit in practice anyways, where there are pending batcher transactions in the global mempool. Individual batcher transactions are cheap enough that it's probably not worth the extra effort and complexity to add persistence.
Depending on the outcome of our batcher hardening investigations in https://github.com/ethereum-optimism/optimism/issues/12123 we might conclude that we want to implement some sort of persistence for the batcher and/or txmgr.
At this point I lean to not do this, and instead live with possibly sending duplicate data after restarts. We already have the past batcher tx check at startup, so this is a super rare case to hit in practice anyways, where there are pending batcher transactions in the global mempool. Individual batcher transactions are cheap enough that it's probably not worth the extra effort and complexity to add persistence.