Maps GitLab's responses onto the forge sentinels released in v0.13.0, and
implements spec 0009 D4: this is the one provider that can tell a missing
project from a project with no releases, so it stops answering both the
same way.

The split is real but it does not live where the spec's wording implies.
A missing project arrives as an SDK error and is named ErrNotFound by the
mapper. An empty list is not an error at all — the project exists and
simply has no releases yet — so it falls through and gets
ErrReleaseNotFound. Two different code paths, one for each answer.

There is deliberately no status check for the 404. The SDK errors on one,
so a branch testing for it is unreachable — and the original code carried
exactly that dead check. Writing it again is what a mutant caught: merging
the two branches changed nothing, because only one of them was ever
reached. Part of why the answers looked merged is that only one was really
being produced, and it had no sentinel at all.

Rate limiting is settled before permission. GitLab answers a limit with
429; an exhausted budget advertised on a 403 is honoured too, for an
instance behind a proxy — and GitLab spells that header without the X-
prefix, so both spellings are read.

The status comes from the response where the SDK returned one and from
*gitlab.ErrorResponse otherwise, since some paths surface only the typed
error.

Asset downloads map through refuseRaw, being a direct request to a URL the
release author supplied rather than an SDK call. Nothing in the
PRIVATE-TOKEN pin changes, and its suite passes untouched: the foreign
host, the redirect, the scheme downgrade and the bare-host normalisation
cases.

TestGetLatestRelease_Empty asserted on the message text, which is the
substring matching these sentinels exist to replace. It now asserts the
sentinel, and that it is NOT the other one.

Implements forge spec 0009 D1, D2, D3, D4 and D7 for this adapter.