Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/web/app/api/v1/management/me/lib/api-key-response.test.ts`:
- Around line 35-160: Add a test to document the behavior where
organizationAccess.accessControl.read is true and environmentPermissions.length
=== 1: call buildApiKeyMeResponse with baseAuthentication plus
organizationAccess { accessControl: { read: true, write: false } } and a single
environmentPermission (use environmentPermission("env-id","read")), mock
getEnvironment to return the environment object (include createdAt/updatedAt
dates and projectId), and assert that the response is the legacy
environment-shaped payload (status 200 and JSON matching id, type,
createdAt/updatedAt ISO strings, appSetupCompleted, and project { id, name })
and that getEnvironment was called with "env-id"; place the test alongside the
other buildApiKeyMeResponse tests.

In `@apps/web/app/api/v1/management/me/lib/api-key-response.ts`:
- Around line 21-29: The current branching silently falls through when
hasOrganizationAccess(authentication, OrganizationAccessType.Read) is true and
authentication.environmentPermissions.length === 1, causing inconsistent
legacy-shaped responses; change the logic so that if hasOrganizationAccess(...,
OrganizationAccessType.Read) then always return
Response.json(buildApiKeyMetadataResponse(authentication)) (no nested length
check), otherwise keep the existing environmentPermissions length !== 1 =>
return null check and fall through to the legacy environment-shaped response for
length === 1; update the code paths around hasOrganizationAccess and
buildApiKeyMetadataResponse and add a unit test that constructs an
authentication with hasOrganizationAccess true and environmentPermissions.length
=== 1 asserting the metadata response is returned.