How to transition a task into a job for update procedure?

The "HttpPushUriXYZ" properties are not needed; these work in conjunction when the client performs a POST to the URI shown in "HttpPushUri". When working with MultipartHttpPushUri, the parameters are all described in the request body when performing a POST to the URI shown in "MultipartHttpPushUri". So, skip step 1 entirely.

Q1: The Task at this point is done since it has transitioned. So, TaskState would be "Completed".
Q2: The response would be the operation result. Since the operation is transitioning to being managed via a Job, this would be an error response body as shown in the "Update operation response management" section of the white paper you've just read. Effectively this means the POST operation to the MultipartHttpPushUri is done.

Q3: No, the task is done at this point and is no longer needed.
Q4: Same as above; the task is done so the response for a GET on the task monitor will either be the error response object described in "Update operation response management", or could be a 404 if the service cleaned up the task monitor.

Essentially in this flow, the task produced reflects the POST operation to the MultipartHttpPushUri. Once the transition to a job is performed, the original operation is complete, but further work is needed to monitor the flow of the update. While it would have been better to keep everything in the confines of the original task, there is a backwards compatibility issue that can be encountered: tasks do not pause and wait for user intervention, so existing clients that monitor tasks would be stuck in a forever loop. We also chose the message path to redirect clients since there could be other messages with other URIs in parallel that a client might need to follow for further operations; simply using the Location header doesn't give the client context of the URI itself (such as the URI for an action that needs to be performed or another object that needs to be polled).

The Redfish Specification itself contains the description of what is allowed inside of the POST request for the multipart update. The "Multipart HTTP push updates" clause of the Redfish Specification contains the details for this. Multipart requests contain multiple forms, and with the way Redfish defines its usage, there's a JSON portion that contains control parameters, an octet stream portion that contains the image, and an OEM portion for anything vendor-specific. The "Multipart HTTP push update" section of the white paper you've been reading contains an example of this as well.

For your follow-up on Q1 and Q2, yes, it's very unfortunate but this is correct. The reason for this is because of OData usage of responses to actions where a return body is not defined in schema; their pattern is to use the OData-defined error response (which Redfish leverages). In hindsight, we should have explicitly defined return bodies for all actions, but doing so at this point would break backwards compatibility. Essentially what we're left with is "Error: Success!" in many cases.