docs(problems): add upstream-error problem page

[samuelwisemanhx]

What does this PR do? (please provide any background)

Adds the missing upstream-error problem page under site/partner/v2/problems/, so that the type URL emitted on upstream-error responses — https://docs.holidayextras.co.uk/partner/v2/problems/upstream-error — resolves to a real page instead of 404ing.

The gateway already surfaces this problem type (RFC 7807 type) when an upstream/downstream service returns an error, but there was no corresponding doc page. This page is formatted to match the existing siblings (bad-gateway, internal-error, etc.): Status/Code table, description, common causes, example response, and resolution guidance. Status is documented as mirroring the upstream service's status, with retry guidance for the transient 5xx case.

Any tech debt?

This only makes the existing type URL resolve. Separately, the error-handling contract across the Apigee fleet is inconsistent (three different problem shapes, plus the gateway's upstream-error envelope currently differs from this documented shape) — that's being picked up as a wider piece of work, not addressed here.

Screenshots / Screencast

n/a — single markdown page, same template as the other problems/* pages. Local Jekyll build not run (repo needs rvm Ruby 3.2.0); the page contains no internal links for html_proofer to flag. CI build will verify.

[gopika-bindhu]

I noticed we've added a separate upstream-error.md alongside bad-gateway.md.

I'm trying to understand the distinction between the two. Since UPSTREAM_ERROR appears to represent an upstream dependency failure, it seems closely related to HTTP 502 Bad Gateway.

Do we expect partners to handle UPSTREAM_ERROR as a distinct problem type with its own semantics, or is it simply our representation of a Bad Gateway scenario?

If it's the latter, having both bad-gateway.md and upstream-error.md may introduce some duplication and could be confusing for partners. We might instead:

document UPSTREAM_ERROR within bad-gateway.md, or
keep only upstream-error.md and state that it is returned with HTTP 502.

On the other hand, if UPSTREAM_ERROR is intended to be a first-class problem type that clients should explicitly handle, then a dedicated upstream-error.md makes sense

For the current bug, the HTTP status 400 Bad Request seems correct because the issue is caused by missing or invalid fields in the client request. However, the problem type/code UPSTREAM_ERROR feels misleading here because it suggests a dependency or downstream service failure. Otherwise partners may think the issue is temporary or service-side and retry the same request, when they actually need to correct the payload.