op-batcher: does not shutdown gracefully

When we try to shutdown the batcher it often:
* takes several seconds
* logs errors and warnings
* exists 137 (SIGKILL)

See these Kurtosis logs:
```
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=info msg="Handling receipt" id=af9623e8f11b1095a218c924586ca936:0
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=warn msg="Transaction failed to send" tx_id=af9623e8f11b1095a218c924586ca936:0 err="transaction manager is closed"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=error msg="error waiting for transactions to complete" err="transaction manager is closed"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=warn msg="main loop returning"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=info msg="Receipt processing loop done"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=info msg="DA throttling loop done"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=info msg="Batch Submitter stopped"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=info msg="balance metrics shutting down"
2025-02-22 08:22:07 t=2025-02-22T08:22:07+0000 lvl=info msg="Batch Submitter stopped"
```

These lines seem to conflict with this comment:
https://github.com/ethereum-optimism/optimism/blob/a10fd5259a3af9a465955b035e16f516327d51d5/op-batcher/batcher/service.go#L413-L417

since the tx manager being closed results in an error waiting for transactions to complete.

This could probably be cleaned up. If we shutdown straight after startup, it shuts down cleanly (probably because there are no txs in flight yet).

Start in op-batcher/batcher/service.go, especially the shutdown logic around the linked comment at lines 413-417. Reproduce shutdown with in-flight transactions using the Kurtosis scenario and trace the transaction manager and receipt-processing loops. Done means the batcher shuts down gracefully without transaction-manager errors, warnings, or an exit 137.

Written by the indexing model from the issue text.