fix: restore embedded wiki images and optimize vector sync

offline-backend-20260512/backend/README.md

@@ -777,15 +777,24 @@ processed Wiki content. A knowledge base uses exact NumPy cosine similarity
 only after its whole Wiki has completed one coherent vectorization pass; until
 then internal search calls WeKnora's Wiki-page search/list API and reads the
 matched Wiki pages. It never falls back to raw documents or chunks. The local
-vector feature is disabled by default. Configure
-`llmwiki.local_wiki_index.embedding` first, then enable `enabled`,
-`sync_enabled`, and `internal_search_enabled` in `config.yaml`.
+vector feature is disabled by default. Configure the three
+`llmwiki.local_wiki_index.embedding` values (`model`, `base_url`, and
+`api_key`), then change only `enabled` to `true` in `config.yaml`. Manual
+vectorization is the default. Set `auto_sync: true` only when periodic
+background synchronization is wanted; the scheduler waits one full interval
+after startup before its first scan, so boot does not trigger a rebuild.
+`database_batch_size` caps each vector insert statement (default `50`) while
+the page replacement remains atomic, preventing a large Wiki from flooding
+the SQL connection in one statement.
 The optional `embedding.dimensions` value is used only to validate the returned
 vector size and build the index fingerprint; it is deliberately not sent in
 the embedding request because fixed-dimension BGE/OpenAI-compatible endpoints
 may reject that extra field with HTTP 400. Omit it to discover the dimension
 from the first successful response.
 
+Embedding failures log the upstream HTTP status and a bounded response body.
+The client never sends a `dimensions` request parameter.
+
 The migration creates `llmwiki_wiki_pages`, `llmwiki_wiki_vectors`, and
 `llmwiki_wiki_sync_states`. Wiki Markdown and normalized float32 vectors are
 stored in DeerFlow's configured SQL database. Multi-worker sync is protected by
@@ -839,6 +848,13 @@ system conversation-deposit knowledge base. Private or unpublished bases are
 never exposed by this route. Anonymous consumers can discover the available
 public Wiki libraries through `GET /api/public/llmwiki/knowledge-bases`; each
 entry deliberately contains only the DeerFlow mapping `id` and display `name`.
+Protected `resource://` and supported object-storage images are fetched through
+the current mapping instead of being exposed as upstream URLs. Authenticated
+readers use `GET /api/llmwiki/knowledge-bases/{id}/files?file_path=...`; public
+readers use the corresponding `/api/public/llmwiki/...` route, which requires a
+published mapping. The embedded WeKnora guard applies the same mapping-scoped
+proxy to document previews and Markdown images, including images inserted after
+the drawer/page first renders.
 
 Wiki management also provides **导出 Excel**. `GET
 /api/llmwiki/knowledge-bases/{id}/wiki/export.xlsx` exports every processed Wiki