refactor: normalize mock API module exports and naming (#388)

[MarcusDavidG]

Summary

Fixes #388.

Problem

lib/api/mock.ts's export {} block was a flat, unsorted list of 13 symbols spanning three conceptually distinct categories — mutable fixture data, control/setter functions, and a standalone dev tool. There were no comments distinguishing them, making it unclear to new contributors whether mockConnections is a function or a data store, or why replayMockEvent doesn't follow the mock* method naming convention the API delegates use.

Changes

lib/api/mock.ts

• Split the single flat export {} block into three clearly labelled sections:
  • Fixture data — communityStates, getCommunityState, mockConnections, mockPrivacySettings, mockReports
  • Controls — MOCK_META_VERSION_OVERRIDE, applyMockScenario, resetMockData, setMock*
  • Standalone tools — replayMockEvent
• Added a ## Export naming conventions section to the module-level JSDoc documenting all three categories and explaining why replayMockEvent is intentionally separate from the mock* API-method delegates.

lib/api/mock/domains.ts

• Updated MOCK_API_PUBLIC_REEXPORTS with matching section comments and an expanded JSDoc so the contract document stays in sync with the module.

test/mock-api-structure.test.ts

• Updated the 'application consumers depend on the API boundary' test to accept @/lib/api/factory as a valid import path for nav.tsx, since that narrower import was introduced in Remove unnecessary navigation dependency on the mock API layer #387.

Acceptance criteria checklist

• Mock fixtures, functions, and types follow consistent naming conventions (documented and sectioned)
• Exported symbols have a clear distinction between data and behavior (three labelled export groups)
• Existing API consumers continue to compile without unnecessary changes (no renames, zero callsite changes)
• No behavior or fixture values changed