Resolve Q16/Q17: media_uri at source, Immich out-of-band

- Q16 → image bytes stay in their source (Memos / Nextcloud / Obsidian);
  Phase-3.2 backfill fetches by media_uri. Zero copy.
- Q17 → Immich stays out-of-band; Nexa does not call Immich's smart-search.
- New Q18 carries forward the unresolved sub-question of whether SAIA's
  LiteLLM gateway already proxies an embedding model — a 1-line check that
  could let us skip TEI in 3.1.

docs/11-open-questions.md

@@ -16,10 +16,9 @@ Items that **block progress** and need a human decision before a workflow can be
 
 - [ ] **Q4 — Obsidian sync mechanism.** `system_prime.txt` references Obsidian Context, but the current setup syncs via Nextcloud (`nc.nuclide.systems` → `Notizen` folder, ~200 MB). Should Nexa watch the **filesystem on LXC 105** (NC data dir) or **the Nextcloud WebDAV API**? FS is cheaper, WebDAV is portable.
 - [ ] **Q5 — Karakeep vs. Hoarder naming.** Zoraxy host is `hoarder.nuclide.systems` but containers are `karakeep-*` and Homepage labels it Karakeep. Same product (rename 2024). Pick one display name for docs and prompts.
-- [ ] **Q16 — Image-attachment queue ergonomics (Phase 3.2).** The agreed plan is: in 3.1 we record images as `nexa:Note` with `nexa:pendingVisualIndex true` but don't embed them. Open sub-questions for when 3.2 lands:
+- [x] **Q16 — Image-attachment queue ergonomics → leave bytes at source, reference by `media_uri`.** Zero copy. Memos attachments stay in Memos's data dir, Nextcloud images stay in Nextcloud, Obsidian images stay in the `Notizen` folder; the Phase-3.2 backfill workflow fetches them on demand via the URI scheme. Sub-question on whether SAIA already proxies an embedding model is still worth a 1-line check in the LiteLLM admin UI before deploying TEI — moved to Q18.
-  - Where to store image bytes between capture and indexing? Three options: (a) leave them in their source (Memos attachments dir / Nextcloud / Obsidian), reference by `media_uri`; (b) copy to a staging area on the docker host; (c) push to `s3.nuclide.systems` immediately. **Recommendation: (a)** — zero copy, smallest blast radius.
+- [x] **Q17 — Immich out-of-band.** Nexa does not call the Immich smart-search API. Photo-library queries stay inside Immich; if a Nexa workflow ever needs photo context it will go through a Memos-mediated handoff rather than a direct API.
-  - Does SAIA already proxy any embedding model? If the SAIA backend offers e.g. `mistral-embed` we could simplify 3.1 by skipping TEI. Worth a 1-line check in the LiteLLM admin UI.
+- [ ] **Q18 — Does SAIA already proxy an embedding model?** 1-line check in the LiteLLM admin UI: list models on the Nexa virtual key. If the SAIA backend offers e.g. `mistral-embed`, we can skip TEI in Phase 3.1 entirely. If not, deploy TEI as planned.
-- [ ] **Q17 — Reuse Immich's CLIP for photo-library queries?** Immich already runs CLIP server-side on the photo library. For images that live *in Immich*, querying its smart-search API is cheaper than re-embedding. Is the Immich API key OK to add to the n8n workflow, or do we treat Immich as out-of-band?
 
 ## Identifiers needed (auto-discoverable, but list now if known)