COG-6482 fix: Rearm jest fetch mocking and guard server config

[goran-radonic]

Description

Follow-ups from a review pass over COG-6342 and COG-6343, both already in the 6319 feature branch. Nothing here is broken at runtime; two of them are traps.

jest.setup.ts had enableMocks() followed by dontMock(). dontMock() kills the isMocking predicate for good, and mockResponseOnce only swaps the implementation without turning it back on, so stubbing was dead repo-wide and any unstubbed call went to the real network. enableMocks() alone is what works. Dropping to a bare import is not enough either, it gives you Response and friends but leaves global fetch unmocked. There is a new test that reaches for an unroutable host so neither half can regress quietly.

serverRuntimeConfig.ts gets import "server-only". Without it, pulling that module into a client component makes Next replace COGNEE_BACKEND_URL with undefined at build time and the module silently returns the localhost default, no error anywhere. The package was not installed, so it is added as a dependency: package.json +1 line, lockfile +7, nothing else moved.

Smaller stuff: modulePathIgnorePatterns so the standalone output stops colliding with the root package in jest's haste map, a jest.config comment that contradicted the mapping right below it, two examples recommending a backend URL the browser cannot resolve, and a dead fallback in ApiKeysPage whose import was the only thing keeping it alive.

Three modules the COG-6342 deletions orphaned (switchTenant, workspaceCreationLock, getUserAppState) stay for now. Verified they have no importers, but cognee-frontend is synced from cognee-saas, so deleting only here just invites the sync to put them back. Same reasoning as COG-6480. Left open on the ticket.

Base is the 6319 feature branch, not dev.

Acceptance Criteria

• fetchMock.mockResponseOnce(...) actually intercepts, covered by a test
• Importing serverRuntimeConfig from a client component fails the build
• No haste collision warning after a build
• No example anywhere recommends a URL the browser cannot resolve
• Existing suite still green

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Code refactoring
• Other (please specify):

Screenshots

$ npx tsc --noEmit -p tsconfig.json
(no output)

$ npx jest
Test Suites: 15 passed, 15 total
Tests:       126 passed, 126 total

$ npm run build
✓ Compiled successfully

$ pre-commit run --all-files
6 hooks passed

Also built the image with this branch applied on top of the 6319 packaging commit, since server-only is a new dependency and the two had never been built together: docker build passes, npm ci picks it up, and the container still refuses to start on a malformed COGNEE_BACKEND_URL, serves the right one, and reports healthy. Full round trip against a real backend container works, login and dashboard, all API calls 200.

Pre-submission Checklist

• I have tested my changes thoroughly before submitting this PR (See CONTRIBUTING.md)
• This PR contains minimal changes necessary to address the issue/feature
• My code follows the project's coding standards and style guidelines
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if applicable)
• All new and existing tests pass
• I have searched existing PRs to ensure this change hasn't been submitted already
• I have linked any relevant issues in the description
• My commits have clear and descriptive messages

DCO Affirmation

I affirm that all code in every commit of this pull request conforms to the terms of the Topoteretes Developer Certificate of Origin.