Support `/results/{id}` and `/outputs/{id}` routes

[fmigneault]

Only "/results" is currently supported (similar to "/outputs") due to Testbed14 conformance.
To ensure back-compatibility with similar WPS REST interfaces, these routes to request specific outputs by ID should be added.

see: https://52north.github.io/tamis-rest-api/

To Do

• add endpoint definitions
• add conformance entries
  • e.g.: /conf/core/job-results-async-one as defined in /REQ_job-results-success-async-one.adoc
  • note: there are others to include as well, search for similar job-results-[...] terms
• test that individual items can be retrieved individually as defined by the specification (consider File vs literals and which content they must support/return)
• reuse/extend Job output transform #548
  • Given an Accept header referring to a different type than the original output format, the alternate representation (if it can be mapped), should be returned
  • If the alternate format can be represented, the generated file can be stored next to the original one, with the alternate extension. It should be reused (cached) if requested again afterward.
    For example, a JSON stored under .../{jobId}/{outputId}/file.json could be requested in YAML, which could be stored under .../{jobId}/{outputId}/file.yaml. Requesting Accept: application/x-yaml a second time should simply return that file's contents rather than regenerating it from the JSON.
  • If the alternate representation cannot be mapped (incompatible/unsupported types), raise HTTP 406 Not Acceptable with an appropriate message
• Ensure ../no-such-output error for the case of invalid outputID from the process and/or available results in the job ([OAPROC CODE SPRINT JAN-2026] Feature/no such output (Close #529) opengeospatial/ogcapi-processes#531)

References

• relates to [Feature] Job request/response documents #240
• relates to GD-534
• relates to OGC09-29