docs(arch): record the seams v1.4 actually produced, and close the one reverse dependency

[mrsibe]

Closes #60.

This turned out to be an acceptance audit first: after #66–#73 the seams the issue planned had mostly already formed, so two of its four acceptance items were satisfied and the work is a documentation update plus one narrow code fix — not the architecture refactor the title suggests.

Acceptance item	Before this PR
architecture.md names the three seams, their implementations, and the IPC → service → db call path	Partial — Retrieval was documented; Document and Application were never named; no call path appeared anywhere
Every v1.4 module sits behind one of the seams	Met, now recorded
No new service reaches getDatabase() from outside the Document/Application layers	One instance — fixed below
The document lists the seams considered and rejected	Not met — added

The seams are named as they exist, not as the issue guessed

#60 proposed DocumentParser, SourceStore and CitationService. None of the three exists, and none was needed:

Guessed	Reality
DocumentParser	IDocumentLoader (already an interface, five implementations) + FileParserService for dispatch
SourceStore	Not extracted. KnowledgeService owns Document persistence orchestration; the provenance helpers take the DB handle explicitly
CitationService	Never created. Citation parsing/resolution and source-anchor mapping are stateless and shared by main and renderer
Retriever	Exists and was already documented

Application is written up as an architectural boundary, not a class, so nobody goes looking for the ApplicationService this document would otherwise imply.

The one code fix

src/main/protocol/documentProtocol.ts (added by #116) queried documents.localFilePath itself — the only v1.4 module reaching the database from outside both permitted layers.

Recording that as a "known exception" would mean accepting a brand-new architectural exception at the moment #60 closes, and the fix is cheap, so it is fixed:

• KnowledgeService.getDocumentLocalFilePath(documentId): string | null — deliberately narrow rather than reusing getDocument(). The handler needs "a readable file for this id", not a whole Document row. No SourceStore-style repository was invented for it — one method on the existing Document seam, no new class/interface/factory.
• registerDocumentProtocolHandler() now takes the resolver, so the protocol layer imports no database, no Drizzle and no schema at all:

before:  knownote-doc:// → getDatabase() → documents
after:   knownote-doc:// → getDocumentLocalFilePath(id) → getDatabase() → documents.localFilePath

• src/main/index.ts and the packaged smoke test inject it. The main-process wiring reads knowledgeService lazily because it is constructed later in startup — noted at the call site rather than reordering startup for it.

A guard, not a comment

test/architectureBoundary.test.ts fails if anything under src/main/protocol/ imports the database, Drizzle or the schema, or calls getDatabase(). It has a self-check so it cannot pass by scanning nothing, and I verified it by injecting the import back: it reports documentProtocol.ts imports ../db and fails.

I did not extend the design-token guard or build a general static analyser for this — one focused rule for the boundary this issue actually constrains.

Recorded honestly, not papered over

Three handlers (noteHandlers, notebookHandlers, and part of chatHandlers) still call db/queries instead of a service. That predates v1.4, and #60's non-goals forbid removing a legacy path before a real feature exercises the replacement — so the document says so rather than implying the boundary is uniformly clean. No handler calls getDatabase() itself.

Review fix: the guard had a false negative

Found in review, and it was a real hole rather than a style point. The matcher caught an exact ../db plus the /db and /db/schema suffixes, but not ../db/queries — which is precisely the pattern this PR's own architecture document records as a database-reaching legacy path. So import { someQuery } from '../db/queries' in the protocol layer would have passed a guard whose stated job is to prevent it.

/(^|\/)db(?:\/|$)/ now treats the whole db subtree as the boundary: ../db, ../db/schema, ../db/queries, ../../db/foo. It still does not fire on db-utils or @shared/dbx, and a table-driven test pins both directions so the rule cannot quietly become leaky or noisy.

Verified by injecting the exact miss back, then restoring:

inject:  import { getNotesByNotebook } from '../db/queries'
result:  ✖ the protocol layer does not reach into the database
         + 'src/main/protocol/documentProtocol.ts imports ../db/queries'
restore: ✔ 4/4 pass

The seam work itself is unchanged: the narrow KnowledgeService query, the injected resolver, the lazy wiring and the architecture document are as reviewed.

Verification

• npm run typecheck — all three projects
• npm test — 261 pass / 0 fail (3 new: the boundary guard)
• npm run build:unpack && npm run smoke:packaged — executed on the packaged app, 20/20 checks, including knownote-doc:// serves an owned document and 404s an unknown id through the newly injected resolver. That is the regression that matters for this change, and it covers both branches (found → serves bytes, not found → 404)
• npm run check:design, npm run lint (0 errors, 107 warning baseline unchanged), npx prettier --check
• docs/architecture.md is additive only: 94 insertions, 0 deletions

Not touched, per the issue's non-goals

KnowledgeService structure, SourceStore, a CitationService, directory layout, the Model seam (#44 owns it), and the legacy db/queries handlers. No follow-up architecture round should be needed — the point of this PR is that reality is now written down and the one reverse dependency is gone.