Fill the contents of the same dialogue area used for Accept/Delay with the Delay options as buttons. Effectively, this becomes like a "wizard" pattern.
This helps indicate (strongly cue) that selecting one immediately continues the execution flow, and does so away from this screen, rather than that another action will be needed to continue flow and that the person using the app will be able to stay on the current screen and waffle between multiple radio options before continuing (e.g. something like selecting one, changing their mind, selecting a different one, then finally record their selection to continue the flow).
Just like a radio control, this maintains the understanding that only a single choice can be selected (due to the cue that selecting a choice will continue flow in navigating from this screen).
which then automatically puts them back into the main screen without any confirmation as it is easy to change this status.
Note: This is good, but I would still generally recommend that you make sure the back button can revert state and return the person using the application to this dialogue. I wouldn't consider it a high priority per se in a situation where the state being represented by the dialogue can still be later edited easily, but it helps maintain consistent UI interaction and reduce friction within that common paradigm.
Inadvertent UI interaction is not entirely uncommon on mobile, and beyond that it's generally always best to make actions reversible in one way or another, short of their necessary outcome creating an irreversible situation (in which case secondary confirmation should be used, but you've made clear this isn't a situation of that type). While being able to edit the state again certainly counts, when people make mistakes they frequently try to "back up", and having to instead "move forward" to a new editing task can add to frustration for some. It's best to provide allowances for both models of interaction, but also not necessary per se so long as one or the other is available (when in doubt, I'd personally choose to be able to still edit the related element state at a later time, if it was only either-or).
Extra info: there can be up to 15 options to select from so it must be dynamic in that it can show either 2, 15, or anywhere between amounts of options.
This button based strategy still works well in a situation where you end up with a large list, as you can provide appropriate UI controls that change depending on the list size to ease the selection task. Obviously the dialogue container needs to be crafted in such a way that it can grow vertically.
The first benefit of this over a dropdown is that it avoids the frequent pitfalls of dropdowns on mobile in terms of inconsistent and sometimes even touch unfriendly implementations between OSes/OS versions, and allows you to place appropriate spacing around your button controls. If you need more information provided alongside each button or only with certain buttons, you can craft something which does so in a clean fashion.
The second is that if you end up with an inordinately long list, you can have a filter field at the top to allow users to reduce the visible list to something manageable.
Finally, a dropdown is no better than a radio control in implying that interaction with it will result in a flow navigation event. Buttons are generally considered to cue that interacting with one will result in some kind of flow or navigation from the application. It could certainly be argued that a radio control or dropdown with no other controls simultaneously visible can be inferred to result in an application flow event on selection, but I would caution that while this is a logical inference to make on seeing that, it's also not consistent with how these controls are more commonly used and as such can still create a sense of frustration. I personally would provide some kind of additional flow intent button (e.g. "submit", "continue", etc.) if using a radio or dropdown control.