Two-dimensional Dynamic Programming
When the options depend on a mode
The second dimension is not a position. It is which situation you are currently in.
Key idea
A second dimension that is not an index
So far the second index has been a position in something. It does not have to be. When the available choices depend on what happened recently, the second dimension is a mode.
The state becomes: the best answer at position i, given that we are currently in mode m. One row of the table per mode, and the transitions say which modes can follow which.
Why it works
Design the modes first, on paper
List the situations you can be in, and for each, list what you may do and where it takes you. Do that before writing anything, because the code is a direct transcription of that list and is very hard to derive without it.
Three modes cover a process where you may hold something, have just released it, or be idle: holding, just released, and free to act. Just released is a mode rather than a moment because it restricts what may happen next.
Write the list out as data before writing any loop. Doing it this way makes the missing arrow obvious: nothing goes from just released straight back to holding, which is exactly what the pause means.
Gotcha
Read the previous step, not this one
All three modes have to update from the values as they were at the end of the previous step. Assigning them one at a time lets an already-updated mode feed into the next, which allows two actions in a single step and quietly defeats the pause.
Take a snapshot of all three into a tuple before touching any of them, which makes it impossible. This is the same discipline as U13's edge-limited relaxation, and it fails the same way: silently permitting more moves than the rules allow.
Tip
The answer is not always the last mode
Finishing while still holding something is never better than having released it, so the answer is the best of the modes that end empty-handed. Including the holding mode in the final maximum would report a value that was never realized.
Deciding which modes are acceptable end states is part of the design, and it is easy to skip when the transitions were the hard part.
Key idea
Why this is a table at all
Written as three variables it does not look like a table, and it is one: three modes times n positions, with the space optimization from U14's step four already applied.
Writing it as an explicit table first, with a row per mode, is the safer route while the transitions are being worked out. Collapse it afterward.
Cost
Cost
One pass with a fixed number of modes, so O(n) time and O(1) space once collapsed, or O(n times modes) space as an explicit table.
The mode count is a constant, so it disappears from the complexity while being the whole difficulty of the problem. That is worth saying, because the stated complexity makes the problem sound easier than it is.
Why is just-released its own mode?
In a process where the step after releasing must be idle, why model just-released separately rather than merging it with free?
Best Time To Buy And Sell Stock With Cooldown
Read the constraints first and let them tell you what complexity is expected. Derive the approach, implement it, run the tests, and submit when it passes.