Investigate unused export surface in apiClient and backend utilities

[rendall]

Summary

knip is now clean after the current Priority 4 cleanup pass, but that required suppressing unused-export noise from two files that may represent intentionally exported utility surfaces:

• src/apiClient.ts
• src/lib/backend-utilities.ts

We should investigate whether these exports are truly part of the supported reusable surface, whether they are consumed indirectly or externally, or whether some can be narrowed/removed.

Why this needs a follow-up

We do not want to turn the current Priority 4 pass into a larger architecture or public-surface cleanup.

However, the current knip output identified these exports as unused within the repo:

Unused exports (18)
toSlug                             src/apiClient.ts:24:14
getSelf                            src/apiClient.ts:60:14
getAllUsers                        src/apiClient.ts:76:14
getAllTopics                       src/apiClient.ts:247:14
objToQuery                         src/apiClient.ts:294:14
isGuestId                          src/apiClient.ts:308:14
isValidEmail                       src/apiClient.ts:314:14
isTopic                            src/apiClient.ts:342:14
getHttpCookie                      src/apiClient.ts:352:14
adminUnsafeUserProperties          src/lib/backend-utilities.ts:89:14
publicUnsafeUserProperties         src/lib/backend-utilities.ts:94:14
isAdminSafeUser                    src/lib/backend-utilities.ts:146:14
isPublicSafeUser                   src/lib/backend-utilities.ts:150:14
nowPlusMinutes                     src/lib/backend-utilities.ts:301:14
getTokenClaim                      src/lib/backend-utilities.ts:378:14
isError                            src/lib/backend-utilities.ts:497:14
HeaderList                  class  src/lib/backend-utilities.ts:526:14
validatePassword                   src/lib/backend-utilities.ts:541:14

There is a plausible explanation that at least some of these are intentionally exported so downstream/custom frontends or integrators can reuse them, but we have not validated that.

Investigation goals

1. Identify whether these exports are used anywhere indirectly, externally, or in documented extension workflows.
2. Determine whether either file is intended to act as a reusable/public utility surface.
3. Separate exports into:
   • clearly required/public
   • clearly internal but currently unused
   • uncertain / needs documentation
4. Decide whether the repo should:
   • keep these exports and document their role, or
   • narrow/remove some of them in a later focused cleanup.

Suggested approach

• Search repo docs, examples, and integration guidance for references to these utilities.
• Review whether any exported functions/classes are part of implied consumer API surfaces.
• If needed, add minimal documentation for intentionally supported exports.
• Defer any removals to a dedicated scoped cleanup after that review.

Current handling

For now, knip suppression/configuration is being used so the current Priority 4 pass can stay focused and avoid accidental surface-area churn.