OAuth error callback reflects parameters without explicit Content-Type header

## Summary

The OAuth error callback handler in `packages/gatekeeper-cloudflare/src/cloudflare.ts` (L124-127) reflects `error` and `error_description` query parameters directly into the response body without an explicit Content-Type header.

## Affected Code

```typescript
const error = url.searchParams.get("error");
if (error) {
return new Response(`${error}: ${url.searchParams.get("error_description")}`);
}
```

The default Content-Type for `new Response(string)` is `text/plain` in modern runtimes, which mitigates XSS in current browsers. However, explicitly setting the header is defensive practice and prevents issues if the response is ever proxied or consumed by a component that infers content type differently.

## Suggested Fix

Set an explicit Content-Type header:

```typescript
return new Response(`${error}: ${url.searchParams.get("error_description")}`, {
headers: { "Content-Type": "text/plain; charset=utf-8" },
});
```

## Severity

Low. This is a hardening measure rather than an active vulnerability.

Previously submitted as part of PR #66 (closed per contributing guidelines).

Read packages/gatekeeper-cloudflare/src/cloudflare.ts at lines 124-127 and inspect the OAuth error callback response path. Done means responses containing the error parameters explicitly declare text/plain; charset=utf-8 while preserving the existing callback behavior; no specific test is named in the issue.

Written by the indexing model from the issue text.