0.10.3

See CHANGELOG.md for the full history.

Four fixes, no new surface and no behaviour change for a healthy vault. Three of them concern
things this plugin writes into your vault and later reads back — index caches and the review
inbox — where the file can be changed between the write and the read by sync, another tool, or
simply by the plugin racing itself.

Security

• A failed tool call no longer tells the client where your vault lives. Tool
  failures are reported in-band so the agent can act on them, which makes the
  message text an output channel. Errors this plugin raises are authored and
  were always safe, but an error raised beneath it — Node's filesystem layer,
  Obsidian's adapter — quotes the vault's absolute path, and with it your
  account name and the vault's real folder name. add_memory and
  reindex_vault could both surface one. Absolute paths are now stripped
  before the message leaves; the vault-relative path survives, so the client
  still learns which note failed, and the full message still reaches the log.

Fixed

• A corrupt index file no longer leaves search broken until you reindex by
  hand. Index/chunks.json lives in your vault, so a sync conflict or another
  tool can leave behind a file that still parses as a JSON array but holds the
  wrong shapes. That loaded as if it were fine, and then every search failed
  with an internal error. The index is a rebuildable cache, so the answer is the
  same one a version mismatch already gets: discard it and rebuild.
• The same applies to the other two caches under Index/. A damaged
  embeddings.json could break every vector search, or score a corrupt vector
  into an arbitrary position in your results rather than being discarded. A
  damaged extracted.json could silently switch off the limit on how much
  attachment text one scan may index, and its cached metadata feeds the
  tag-exclusion check — so a malformed entry could have affected which
  attachments were excluded. Both are now validated on load and recomputed when
  they do not hold up.
• A reviewed memory can no longer come back from the dead. Discarding or
  applying an entry rewrites the whole review inbox, and those rewrites are
  serialized so two of them cannot clobber each other. That serialization was
  attached to an object the plugin replaces whenever any setting changes, so a
  settings commit landing between two clicks in the review pane left the first
  rewrite unwaited-for — and the entry you had just discarded reappeared. The
  lock now outlives the settings change.

---

Verify the assets: sha256sum -c SHA256SUMS, and gh attestation verify main.js --repo nfoav8or/coder-engram for signed build provenance.