OP Conductor Pause Issue in VM Based Setup

### Bug Description

When deploying OP Conductor in a VM-based setup and initiating it with the recommended flags, the active sequencer (OP Geth and OP Node) unexpectedly pauses. Upon starting OP Conductor, it flags the sequencer as unhealthy.

### Steps to Reproduce

1. Ensure all components of the L2 system are operating normally, with the sequencer running as expected.
2. Deploy OP Conductor on the active sequencer using the following command:
```
./bin/op-conductor --consensus.addr=127.0.0.1 --consensus.port=50050 --execution.rpc=http://127.0.0.1:8545 --healthcheck.interval=1 --healthcheck.min-peer-count=2 --healthcheck.unsafe-interval=5 --log.format=logfmt --log.level=info --metrics.enabled=false --node.rpc=http://127.0.0.1:8547 --raft.server.id=abc123 --raft.storage.dir=/conductor/raft --rpc.enable-admin=true --rpc.port=9549 --rollup.config=./rollup.json --raft.bootstrap=true
```

3. Observe that the OP Conductor process stops the active sequencer and then flags it as unhealthy.

### Expected Behavior
The OP Conductor should deploy without interrupting or pausing the active sequencer's operation, and no unhealthy status should be flagged.

### Environment Information

- Operating System: Ubuntu 22.04.5 LTS
- System Architecture: 64-bit
- git: 2.34.1
- go: 1.21.5
- node: 20.18.0
- foundry: 0.2.0 (a428ba6)
- make: 4.3
- jq: 1.6
- direnv: 2.35.0
- op-geth repo tag: [v1.101408.0](https://github.com/ethereum-optimism/op-geth/tree/v1.101408.0)
- optimism repo tag: [op-contracts/v1.5.0](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v1.5.0) (at the time of contracts deployment)
- optimism repo tag: [v1.9.1](https://github.com/ethereum-optimism/optimism/tree/v1.9.1) (at the time of making builds of all the components)

### Configurations
- Consensus Address: 127.0.0.1
- Consensus Port: 50050
- Execution RPC: http://127.0.0.1:8545
- Healthcheck Interval: 1
- Healthcheck Minimum Peer Count: 2
- Healthcheck Unsafe Interval: 5
- Log Format: logfmt
- Log Level: info
- Metrics Enabled: false
- Node RPC: http://127.0.0.1:8547
- Raft Server ID: abc123
- Raft Storage Directory: /conductor/raft
- RPC Admin Enable: true
- RPC Port: 9549
- Rollup Config: ./rollup.json
- Raft Bootstrap: true

### Logs
Please find attached the logs from **OP Geth**, **OP Node**, **OP Batcher**, and **OP Conductor**.

**OP Geth Log**

**OP Node Log**

**OP Batcher Log**

**OP Conductor Log**

### Additional Questions
I have a few additional questions for clarification:

1. **Discovery of OP Conductor Instances**: How do OP Conductor instances discover each other? We are experiencing issues with peer discovery when transferring sequencer leadership in a VM-based setup.
2. **OP Conductor Start Order**: What is the recommended order for starting the OP Conductor? Specifically:
- Should the OP Conductor be initiated before making the necessary configuration changes in the OP Node to enable it?
- Should the OP Conductor be started on the currently active sequencer, or would it be better to initiate it on passive sequencers?
3. **Bootstrap Configuration for Active Sequencer**: Is it essential to start the OP Conductor on the active sequencer with the `--raft.bootstrap` flag enabled? Alternatively, could we designate an inactive sequencer as the Raft bootstrap node by enabling the same flag `--raft.bootstrap`?