Image component tests mock fetchCloudinaryImageMetadata as an internal module — logic bugs there survive tests invisibly

[ooloth]

Current state

ui/elements/image.test.tsx mocks @/io/cloudinary/fetchCloudinaryImageMetadata wholesale via vi.mock(...). fetchCloudinaryImageMetadata is a project-internal module, not an external API boundary — it contains transformation logic (URL construction, metadata extraction) that is part of the system under test. Mocking it disconnects the Image component tests from any real behavior: a bug in fetchCloudinaryImageMetadata's URL construction or metadata extraction would not cause any Image test to fail. No dedicated unit tests for fetchCloudinaryImageMetadata itself exist in the codebase to compensate.

Ideal state

• Image component tests exercise the real fetchCloudinaryImageMetadata function
• The true system boundary — the HTTP call to the Cloudinary API — is mocked at the network layer (e.g. via msw or a test-scoped mock of fetch)
• A bug in fetchCloudinaryImageMetadata's URL construction or metadata extraction causes at least one Image test to fail

Out of scope

• Removing mocks for genuinely external dependencies (the Cloudinary API network call should still be intercepted)

Starting points

• ui/elements/image.test.tsx — vi.mock('@/io/cloudinary/fetchCloudinaryImageMetadata') setup at the top of the file
• io/cloudinary/fetchCloudinaryImageMetadata.ts — the module being mocked; transformation logic lives here

QA plan

1. Remove the vi.mock('@/io/cloudinary/fetchCloudinaryImageMetadata') call and mock only the network boundary instead
2. Introduce a deliberate bug in fetchCloudinaryImageMetadata (e.g. return an empty string for src) — expect at least one Image test to fail
3. Revert the bug — expect all tests to pass

Done when

The Image component tests fail when fetchCloudinaryImageMetadata returns wrong data, with only the Cloudinary HTTP boundary mocked.