Part 4: Allow job start to return 202 instead of 200

Referring to this requirement:

https://github.com/opengeospatial/ogcapi-processes/blob/02627da57ab4782fdf41d8e8f421dd3c9b422eb6/extensions/job_management/standard/requirements/job-management/start/REQ_response.adoc?plain=1#L6C1-L6C110

When a job is pending execution with status: created, and that POST /jobs/{jobId}/results is requested to trigger its execution, an implementation can still choose this "trigger" to simply consist of placing the job in queue for processing (as if it was directly submitted originally by Prefer: respond-async).

Therefore, even if the execution trigger was acknowledged, it might still not have been performed "yet", due to pending resources acquisition or other prerequisites. For this reason, a server might prefer to highlight this situation using HTTP 202 Accepted rather than "HTTP 200 OK". The HTTP 200 OK can give the wrong impression that resources (i.e.: GET /jobs/{jobId}/results) would now be available, when in fact they are almost certainly not yet ready for a long processing graph/workflow.

See https://github.com/opengeospatial/ogcapi-processes/issues/451#issuecomment-2426624016 for details about the execution modes.

Start with extensions/job_management/standard/requirements/job-management/start/REQ_response.adoc and read the linked execution-mode discussion in issue 451. Update the requirement so a pending job trigger may return HTTP 202 instead of HTTP 200, and verify that the wording matches the described queued-execution behavior.