test: add unit tests for api-client, usePermissionChecks and useUserPresets #80

TL;DR: Add unit tests for the three load-bearing, currently untested service/permission/preset modules, so the rest of the service-layer epic can refactor with a safety net.

Context

Sub-issue of #79 (service-layer hardening). api-client.ts (865 lines), usePermissionChecks.ts (210), and useUserPresets.ts (371) have zero unit tests, while they handle API transport, permission gating, and persistence of all user UI state. RelationChecker is the only tested service and can serve as the pattern.

Acceptance Criteria

• Unit tests for DirectusApiClient core paths (success + error/retry) with a mocked transport
• Unit tests for usePermissionChecks (role resolution, allow/deny outcomes)
• Unit tests for useUserPresets (load, save, defaults)
• Tests run in the existing Vitest setup and pass
• Coverage for these three modules meaningfully above zero

Scope

In Scope:

• Test files for the three modules, with mocked SDK/transport
• Test fixtures/mocks reusable by later sub-issues

Out of Scope:

• Refactoring the modules themselves (→ fix: usePermissionChecks race condition and PII in logs #81, refactor: unify error handling across the service layer #82, refactor: split DirectusApiClient into domain clients #83)
• E2E tests

Technical Implementation

• Targets: src/services/api-client.ts, src/composables/usePermissionChecks.ts, src/composables/useUserPresets.ts
• Pattern: mirror the existing RelationChecker spec; mock the Directus SDK (useApi/useStores) and the transport
• Tests live under the existing test/ directory; reuse test/setup.ts

Architecture Reference

• Tests precede/accompany the refactor (→ refactor: service-layer hardening & test coverage #79)

Dependencies

• Blocked by: None
• Prerequisite for: refactor: split DirectusApiClient into domain clients #83 (safety net before the client split)