Knowledge ships as a built-in coworker; the search-and-cite path behind it is never called

[Hotragn]

examples/fintech/agents.yaml and docs/configuration.md both ship Knowledge as one of three built-in coworkers, described as answering "company knowledge questions and cite sources." As configured, knowledge has type: built-in with only a system_prompt — the exact same path as general-assistant. That path has no retrieval step: no document search, no vector lookup, nothing that could produce a real citation. (#58 stops the shipped prompt from claiming an unconditional citation it can't back; it doesn't touch this gap.)

The retrieval-and-cite logic already exists, separately, and is never reached:

• createKnowledgeAgent (server/src/agents/knowledge-agent.ts:3) and createAgentInvoker (server/src/agents/invocation.ts:9) are fully implemented and covered by server/tests/knowledge-agent.test.ts and server/tests/agent-invocation.test.ts. A repo-wide grep for both names outside test files returns only their own definitions — no caller anywhere in server/src.
• Their backing store, InMemoryKnowledgeRepository (server/src/knowledge/repository.ts:22), holds documents, chunks, and ACLs in a Map. It's exercised only by server/tests/knowledge-repository.test.ts; nothing constructs or persists it. Given Take back the two features that only worked on one machine #21's revert of the approval registry and the repetition counter for the same reason, this one shouldn't be wired up as-is either — it needs a table, not a Map, before it's reachable from a route.
• knowledge.yaml documents google-drive and microsoft-onedrive as supported source types. ConnectorAdminService (server/src/connectors.ts:11) only has configureGoogleDrive; there's no configureOneDrive, so a deployment can declare a OneDrive source and never configure it. (The admin UI already says this plainly — app/src/routes/_authed/admin/connectors.tsx:74-77 shows "No setup screen yet" instead of a dead control — so this half of the gap is at least honestly surfaced.)
• ConnectorAdapter (server/src/connectors/contract.ts:19) has zero concrete implementations anywhere in the repo — no Google Drive adapter, no Microsoft Graph adapter.
• runConnector (worker/src/connector-runner.ts:17) is real and tested against that interface, but its only caller is its own test file. worker/src/index.ts is three lines that print workerStatus(); there's no scheduler, cron, or entrypoint that ever calls it.

Net effect: a deployment running the shipped example, or any tenant package that declares a knowledge coworker, has a Bot that answers as if it has authorized company knowledge behind it and never actually searches anything.

Proposed approach, before I touch any code:

1. Replace InMemoryKnowledgeRepository with a Postgres-backed one (documents/chunks/ACL tables), since this has to survive a restart and a second replica, not live in a process.
2. Give the built-in agent type a way to route through createAgentInvoker/createKnowledgeAgent when the coworker is knowledge-backed, instead of always taking the plain system-prompt-only path it shares with general-assistant today.
3. Ship one real ConnectorAdapter — Google Drive first, since configureGoogleDrive's service-account credential flow is already in place — plus a scheduler entrypoint in worker/src/index.ts that actually calls runConnector on it.
4. Leave Microsoft OneDrive as configured: false / "No setup screen yet" for a follow-up rather than landing both connectors at once.

Happy to take this in a different direction if there's a reason Knowledge is intentionally left as a config-only placeholder for now — flagging because the README and both docs files currently describe a coworker that can answer from and cite real company sources, and today it can't.