The first proposer can DoS the rollapp without being slashed

[danwt]

In a newly created Rollapp, the first sequencer registers and becomes the proposer, but the liveness check in x/rollapp/keeper/msg_server_update_state.go:107 is not scheduled until the first state update is submitted. This allows the proposer to deliberately avoid submitting any state updates, effectively performing a DoS attack on the Rollapp without facing any penalties, as no liveness checks or slashing events are triggered without the initial state update, and no forced proposer rotations occur. We are reporting this issue with minor severity since we expect that the Rollapp first sequencer is controlled by the Rollapp’s owner. Additionally, the Rollapp creation and the Sequencer creation messages can be sent in the same transaction to avoid front running. Recommendation We recommend scheduling the liveness event at the time the initial sequencer is registered.

[omritoptix]

yea we should def handle it. sponsorship relies on that.