feat(knowledge): add shared team knowledge bases

[JnyRoad]

Summary

Introduce first-class shared knowledge bases for team collaboration while preserving employee-dedicated knowledge isolation. This PR is intentionally scoped to the shared-knowledge architecture and excludes the unrelated accumulated changes from #237.

Changes

• add explicit dedicated and shared knowledge modes, team bindings, and per-member reader/editor/publisher permissions
• make every bound team consume one globally published head while keeping drafts invisible until publication
• add audited draft, update, publish, reject, and rollback workflows with optimistic concurrency and idempotency controls
• allow an employee-dedicated knowledge lineage to be converted into a new shared lineage without deleting source history
• keep private chats restricted to employee-dedicated knowledge; let team chats read the executing employee dedicated knowledge plus authorized team-shared knowledge
• expose management UI for creation, conversion, team bindings, permissions, version history, and audit history
• add SQLite migration compatibility and regression coverage across API, Harness v2, permissions, retrieval, and frontend flows

Testing

• STAFFDECK_SRT_RUNTIME=<reviewed-runtime-dir> backend/.venv/bin/python -m pytest backend/tests -q — 2088 passed, 13 warnings
• npm --prefix frontend-enterprise test -- --run — 54 files, 265 tests passed
• npm --prefix frontend-enterprise run build — passed
• npm --prefix frontend-enterprise run config:check — passed
• git diff --check upstream/main...HEAD — passed
• npm --prefix frontend-enterprise run i18n:check — one unchanged baseline regex-literal false positive in src/pages/chat/chatHelpers.tsx; tracked by fix(i18n): skip regex fragments in the translation check #223
• changed-path Ruff E9,F,I check — one pre-existing import-order finding in backend/tests/test_public_api_v1.py, reproduced unchanged on upstream/main
• manual browser validation was not run; the affected management and chat-scope flows are covered by component/page tests and the production build

Risks

• SQLite startup migration adds the shared-knowledge schema and preserves legacy knowledge bases as dedicated by default.
• Authorization fails closed across tenant, team binding, executing employee, and permission level.
• Publishing or rolling back changes the one global head read by every authorized bound team; drafts remain isolated until publication.
• The frontend has automated flow coverage but still needs reviewer-side browser validation for the affected roles and routes.