[Bug]: Image URL-guard tests inherit the generic OpenAI fallback

[HaningZS]

Bug Description

The security regression tests in tests/server/generate-image-unconditional-url-guard.test.ts are not isolated from a developer's shell-exported generic OPENAI_API_KEY.

The test helper clears the IMAGE_* provider variables, but production provider configuration also has a generic OpenAI image fallback in applyOpenAIImageFallback(). When OPENAI_API_KEY exists, that server-managed fallback replaces the client-supplied provider config before the route reaches the URL guard exercised by these tests.

Consequences:

• the test that expects a private client base URL to be rejected receives HTTP 200 instead of 403;
• the allow-local test invokes the mocked generator with the unrelated server fallback and no client base URL;
• Vitest's mock diff prints the shell key value as apiKey, which is unsafe for local/shared test logs;
• the tests can stop proving their intended invariant depending on the caller's environment.

This is a unit-test isolation and log-safety defect. It is not a report that the production route leaks credentials or that the SSRF guard itself is bypassable by a remote client.

Safe Reproduction

On current main (ebf665f3), use a non-secret sentinel:

OPENAI_API_KEY=openmaic-test-sentinel \
  pnpm exec vitest run tests/server/generate-image-unconditional-url-guard.test.ts

Both tests fail. The rejection test receives 200 instead of 403, and the second failure shows the mocked provider config using apiKey: "openmaic-test-sentinel" with baseUrl: undefined.

With OPENAI_API_KEY unset, the same file passes 2/2.

Expected Behavior

The URL-guard tests should always exercise the client-supplied OpenAI image configuration they construct, independently of shell provider credentials. Test cleanup should also restore any environment values it masks.

Proposed Scope

• Mask the generic OpenAI fallback variables together with the image-specific variables using Vitest's environment stubs.
• Restore all stubbed values after each test.
• Keep the production provider fallback, SSRF policy, and global test-environment policy unchanged.

Acceptance Criteria

• The focused file passes with OPENAI_API_KEY=openmaic-test-sentinel and with the variable unset.
• The private-network rejection still returns 403 and never calls generateImage.
• The ALLOW_LOCAL_NETWORKS=true case still forwards the client key/model/base URL.
• Dedicated provider-config fallback coverage remains green.
• The full root suite passes with the sentinel exported.
• Formatting, lint, TypeScript, and relevant security tests remain green.

Related context: #1302 fixed the same class of local-environment contamination in a different media test. This file was added later by the SSRF hardening line and is independently affected.

This report and planned fix are AI-assisted and were manually reproduced with a non-secret sentinel.

[HaningZS]

I will work on this issue.

Planned scope:

• preserve the sentinel RED reproduction on current main;
• replace direct environment deletion in this test boundary with restorable Vitest stubs, including the generic OpenAI fallback;
• verify both SSRF outcomes still exercise the client-supplied provider config;
• run the focused security tests, provider fallback tests, full Node 22 quality gates, and the root suite with the sentinel exported;
• perform and report an AI-assisted self-review before requesting maintainer review.

Production provider selection, SSRF behavior, and the global shell-environment policy are out of scope.