feat(df): add REST evaluate checker and wire the real API

Third of three MRs splitting the former policy MR (!3722 (closed)).

Now targets main (!3745 (merged) merged).

Wires the real Dependency Firewall evaluate API, replacing the fail-closed placeholder added in !3744 (merged):

• restChecker evaluates each coordinate through the typed client-go SecurityDependencyFirewall.EvaluatePackage service and maps outcome (allowed/warned/blocked) to a verdict.
• Evaluates against Request.ProjectID (set by the caller), so the checker holds no project of its own; New()/newRESTChecker no longer take a project. New()'s non-fake path returns newRESTChecker instead of the placeholder.
• The ecosystem is normalized to the client-go enum with an explicit switch (npm/pypi/maven/gem); an unsupported value errors before the request rather than becoming a 400 that fails closed.
• Fail open on 404/422 (the firewall is not evaluating this project) is signalled with a typed sentinel errFirewallNotEvaluating; CachingChecker maps it to allow and logs it, so a typo'd repo or under-scoped token is visible rather than a silent allow-all. Fails closed on 5xx/429/401/403/400/network and on an unknown or missing outcome (nil body is guarded).
• Tests use gitlabtesting.NewTestClient for outcome and status-code mapping; one httptest test covers the real HTTP method/path/JSON-body wire format.

Note: Request.Operation is kept for cache-key isolation and diagnostics only — the evaluate API is scoped to project and coordinate and does not accept an operation, so it is not transmitted.

A few small changes ride along that predate the client-go swap (the verdict.Allowed constant, Operation.String(), and Result.Allowed()/Warned() helpers) — they were introduced in the earlier "sync policy review fixes" commit rather than as REST-checker work.

Depends on the client-go Dependency Firewall endpoint (client-go!2998). Until that release is available and the go.mod bump lands, this branch does not compile in CI; do not merge before the client-go release.

Verified end-to-end on gdk-in-a-box against a real linked dependency_firewall_policy: glab df package and glab df npm install block/warn/allow per the API verdict, and fail open (with a log line) when the firewall is not evaluating the project.