The simple answer is, of course, to simply create two forms; one for each button. You can even use a snippet to duplicate most of the functionality of the page, leaving the status dropdown as the only unique item in both pages. Then simply configure one of them as editable and the other not.
If, for whatever reason, you reallyreally don't want to create a second page, you could fix this using security or conditional visibility. Both solutions require an 'isNew' boolean attribute with a default value of True that you set to False when the object is first committed in the before commit microflow. Then you can configure a security xpath constraint that only allows the user to edit Status when [isNew = false()]. Alternatively, you can model two dropdowns with mutually exclusive visibility conditions: an editable one that is visible when isNew is false and a read-only drop-down for when isNew is true.*
Ultimately you're going to have to choose between a solution that creates more bloat in your application and one that leaves you with a more aesthetically pleasing but less transparent model that will be harder to explain to future developers.
*If either of these answers seems like what you're looking for but you're having trouble making sense of my abridged description feel free to drop me a line.
It depends on what it is you want to accomplish. Adding the same attribute as a display only field and as an editable field (dropdown) on the same entity can be done, but when changing the dropdown the display only field will change as well as it is the same attribute. If you need these fields to work independent then you''ll need to implement a second attribute and reuse the enumeration for the status and possibly add some logic with an on change event of the attribute used for the dropdown.