Query on UpdateService schema

Regardless of whether the path of the update is from the deprecated HttpPushUri property or the MultipartHttpPushUri property, the fact that its staged persistently on the manager is currently not shown or controlled by the user. The only difference between the two paths is the fact that the MultipartHttpPushUri path is well-defined in the spec and allows for parameters (like @redfish.OperationApplyTime) to be passed within the request itself as opposed to distinct control properties in the UpdateService resource.

So, in either case, you're free to stage the firmware internally however you see fit. In addition, both paths can utilize the same flow outlined in the Redfish Firmware Update White Paper (DSP2062). One thing to correct in your flow is that at step 1c (assuming the update is monitored entirely with a task and there is no transition to a job), the task should not be completed here; the operation is not finished. Instead, the task should enter a "Pending" state since it's waiting for the StartUpdate request to be invoked. However, since persistency is important for your situation, I would recommend leveraging the job construct (and transitioning from a task to a job); unlike tasks, jobs are required to be persistent across manager resets. DSP2062 shows the general template for how a firmware update can be invoked, a task starts, transitions to a job, and then is finally complete. So the end to end flow could look something like this: