chore: remove dead code and sync the specs that described it

[PolinaGurinovich97]

Description of changes

Knip (production + comprehensive modes) over apps/* and libs/* surfaced code with no callers. This removes what verification confirmed dead and updates the OpenSpec specs that still described it. No behaviour change — nothing removed here had a caller.

Removed from apps/chat

• FileTypeIcon, collect-stream, server-api/models.ts (and the modelsApi singleton it was the only consumer of), rate.api.ts and its spec
• OperationLoaderModal and UploadProgressModal with their specs — stale copies of components that now live in libs/chat-shared/src/file-manager. The app copies had already drifted behind (missing mobile:!w-full), so the risk was someone fixing the dead copy. Their tests duplicated the lib's own line for line, so no coverage is lost.

Removed from apps/chat-api

• list-items-debug, PinConversationDto (absent from the OpenAPI spec — the pin flow goes through conversation-lifecycle.service.ts), and the ManagedConfigProvider placeholder, which threw when resolved and was never registered. The composite provider's comment now reads "(future)" instead of pointing at a stub file that no longer exists.

Kept deliberately

useThemeOptions has zero callers but stays: openspec/changes/add-settings-preferences-tab requires it to survive as the parked theme row's entry point, and docs/architecture.md documents it.

Spec updates in the same change

• model-listing, model-lookup — dropped the frontend server-api helper requirements. The endpoints themselves stay and remain fully specified; a note in each Purpose records that apps/chat reads model metadata through deploymentsApi instead, so nobody removes a live endpoint as unused or restores the helper as missing.
• generated-api-client-integration — dropped the models domain requirement and modelsApi from the required api-client.ts exports
• applications-listing, unified-catalog — modelsApi replaced as the "follow this pattern" example
• chat-hooks-domain-utilities — collect-stream.ts dropped from the list of files that must not be modified

Applicable issues

No linked issue — this came out of a dead-code audit. Happy to add one if you'd like it tracked.

UI changes

None.

Verification

• nx typecheck lint -p chat chat-api — chat green on both; chat-api lint green
• nx test chat-api — 189 files, 3194 tests, all pass
• nx test chat — 157/158 files pass; the one failure (SkillEditorPreview "unrecognized text extension") is a pre-existing flake that times out only under the parallel run and passes in isolation, with no import path to anything removed here
• npm run validate:docs — passes
• chat-api:typecheck reports 767 errors, identical on a clean origin/development checkout — a pre-existing tsconfig.spec.json / project-reference condition unrelated to this change
• Knip re-run after the deletions: production-mode dead files 38 → 31, with no new findings introduced by the removals

Checklist

• I confirm that I don't share any confidential information like API keys or any other secrets and private URLs

🤖 Generated with Claude Code

[github-actions]

✅ security-review: Dead-code removal PR. No new attack surface introduced; several security-relevant patterns improved or removed cleanly.

Run details

[github-actions]

⚠️ code-review: Strong, well-specified backend change (#8784: bearer-auth chat generation) with thorough adversarial tests, complete OpenSpec artifacts, and clean doc/spec sync. Non-blocking nits: a spec-version lockstep gap in header-token.strategy.ts, and the toolset endpoint URL contract narrowed (sse:// now rejected) as a silent breaking change.

Severity	Location	Message
warning	libs/toolset-editor/src/utils/toolsets.ts	Public-contract narrowing shipped without a docs/architecture.md Compatibility note: isValidEndpointUrl (toolset-editor) and ToolsetBodyDto (chat-api) both stop accepting sse:// endpoints, so any toolset previously saved with an sse:// endpoint is now invalid. The change is correct and deliberate — DIAL Core rejects a stored sse scheme with 'invalid URI scheme sse', and the SSE transport is chosen via the transport field over an http(s) endpoint — and the README, .env-adjacent prose, JSDoc defaults, en.json messages, and both specs were updated in the same diff. Only the Compatibility note for the previously documented contract is missing. Non-blocking; a single note in docs/architecture.md and a mention in the PR body would complete it.
nit	apps/chat-api/src/auth/strategies/header-token.strategy.ts:120	Same reasoning, two spellings: the new sub rejection and the pre-existing iss rejection both hardcode their own message strings ('Token is missing a "sub" claim' and 'Token is missing an "iss" claim'), while every other rejected-message in this file is already shared through a small set of helper/const patterns. Harmless duplication; extracting a shared missingClaim(claim) helper would keep the invariant 'no message may drift' as a single place. Pure readability nit, not blocking.
fyi	apps/chat-api/src/auth/strategies/header-token.strategy.ts:119	Order-of-checks speed-up is real but produces a user-visible error-message change: a token with a missing sub now returns AUTH_HEADER_TOKEN_INVALID with message 'Token is missing a "sub" claim' even when it may be expired or deliberately issued for a refresh flow (which legitimately omits sub per OIDC spec). This is intended and documented ('reject before resolving the bucket, so an unusable token costs no DIAL Core round trip'), and the spec's check-order list was updated to include it. Only note: an OIDC refresh token, which may never carry sub, hitting the BFF would now see a sub-specific message rather than an expiry one — which of the two the caller sees first is a diagnostic nuance, not a bug.

Run details