#8329 fix(knowledge): count documents through the reader's access and only where counts are shown

Summary

• v1 knowledge base list, detail, and update returned docCount/tokenCount over every document in the base, including connector documents the caller cannot read. They now count through the caller's access (resolveV1KnowledgeReadAccess), the same way the v1 documents routes already do. v1 detail also now returns its real connectorTypes
• The internal KB list joined document through the full access predicate on every call, but only the Knowledge page shows the totals. The list contract gains includeCounts (default false), and without it the query reads only knowledge_base columns. The service option is countsFor: access, so a count without an access filter can't be written
• React Query: counted lists get their own key beside list(), used only by the Knowledge page and its server prefetch. Document, upload, and connector mutations refresh only the counted lists; KB create, rename, delete, restore, and move refresh both
• Removed getKnowledgeBaseById, whose unfiltered count join ran on every context resolution. Callers use getActiveKnowledgeBaseReference, and single-base totals come only from attachKnowledgeBaseConnectors(kb, access)
• The v2 list keeps returning totals, since its public contract requires them

Type of Change

• Bug fix

Testing

• New app/api/v1/knowledge/route.integration.ts (real Postgres, only auth mocked): a read-role caller sees docCount: 1 for a base holding one upload plus one admin-only connector document on v1 list and detail. All 3 tests fail on the old code
• Search-index policy integration suite and the knowledge service, application, and context unit suites updated and passing
• Type-check, lint, and check:audits pass

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)