Flaky test: CORS only forwards content-type from upstream responses

`graph-explorer-proxy-server > createApp > CORS > only forwards content-type from upstream responses` (`packages/graph-explorer-proxy-server/src/app.test.ts:187`) fails intermittently. It is not related to any current change — it surfaced incidentally during unrelated work.

## Reproduction rate

Genuinely intermittent and not reproducible on demand:

| how | result |
| --- | --- |
| `pnpm test app.test -- -t "only forwards content-type"`, 6 runs | 1 failure |
| same, 25 further runs | 0 failures |
| whole `graph-explorer-proxy-server` package, 8 runs | 0 failures |
| full workspace `pnpm test` | 1 failure observed once, across many green runs |

Both observed failures came from runs with other work in flight, so contention or timing is the likeliest ingredient. Passes consistently when the file is run on its own.

## Ruled out

**Mock queue leakage.** The obvious suspect — `mockFetchOnce` uses `mockResolvedValueOnce`, so a value queued by one test and not consumed would be picked up by the next. But `app.test.ts:71-73` calls `mockFetch.mockReset()` in `beforeEach`, which clears the queue. So a stale one-shot response is not the cause for sequential runs within the file.

## What the test does

```ts
mockFetchOnce(JSON.stringify({ results: [] }), 200, {
"content-type": "application/json",
"access-control-allow-origin": "https://upstream.example.com",
"transfer-encoding": "chunked",
server: "Neptune/1.0",
"x-request-id": "abc-123",
});

const response = await request(app).post("/sparql").set(dbHeaders()).send({ query: "SELECT 1" });

expect(response.headers["content-type"]).toContain("application/json");
expect(response.headers["access-control-allow-origin"]).toBeUndefined();
expect(response.headers["server"]).toBeUndefined();
expect(response.headers["x-request-id"]).toBeUndefined();
```

I was unable to capture the failing assertion — every attempt to reproduce with output captured came back green. So it is unknown which of the four expectations fails, which is the first thing to establish.

## Suggested approach

1. Get the assertion. Run the full workspace suite in a loop with output retained, or temporarily raise reporter verbosity for this file in CI, until it fails once.
2. Suspect the interaction between the mocked upstream `transfer-encoding: chunked` header and supertest/express, which can change how the response is framed and therefore how headers are surfaced — a plausible source of timing sensitivity, given the test only fails under load.
3. Check whether the test depends on a shared port or server instance with a sibling test in the same file (`createTestApp()` is called per test, so verify nothing outside it is shared).

Low priority — a rare CI flake, not a product defect. Filing so a red build on this test is recognised rather than re-investigated.

---

> [!IMPORTANT]
> Internal only — this issue is maintained by the core team and is not accepting external contributions.

Start with packages/graph-explorer-proxy-server/src/app.test.ts, especially the test at line 187 and mock reset setup at lines 71-73. Run the workspace suite repeatedly with retained output until the failing expectation is identified, then check the transfer-encoding, server, and shared-server possibilities described in the issue; done means the flake is explained and the test is reliable.

Written by the indexing model from the issue text.