Fix: Pulse crash-loops when any unwatchable node exists under LIFEOS/

[lmbagley]

Problem

startWatchers() in the wiki module watches LIFEOS_DIR recursively. A recursive watch walks every node beneath its root, and some cannot be opened — unix sockets, FIFOs, dead symlinks, unreadable directories. Those surface as an asynchronous 'error' event on the watcher. The surrounding try/catch only sees synchronous throws, so the event goes unhandled and terminates the process.

Under a supervisor, Pulse then crash-loops for as long as the node exists. Because the walk happens during startup, it presents as "Pulse won't start" rather than "one file is unwatchable", and the only clue is an ENXIO naming a file with nothing to do with the wiki:

error: ENXIO: no such device or address, open '.../MEMORY/<tool>/<name>.sock'
      at emitError (node:events:51:13)
      at #onEvent (node:fs:47:16)

It is easy to miss because it is latent. A long-running Pulse is unaffected when the socket appears — the walk already happened. It only bites on the next restart, which can be weeks later and looks unrelated to whatever created the file. Any tool that puts a socket under LIFEOS/MEMORY/ (a bot, an IPC helper, an editor server) is enough to trigger it.

Changes

1. Narrow the watch roots to what the reindexer actually consumes — DOCUMENTATION_DIR, KNOWLEDGE_DIR, ALGORITHM_DIR.

Watching all of LIFEOS_DIR was simultaneously too broad and too narrow:

• Too broad — MEMORY/ is the busiest subtree in an install (constant .jsonl appends) and the place where non-regular files appear.
• Too narrow — skills/ and hooks/ live under ~/.claude, not under LIFEOS/, so changes there were never watched anyway.

This removes the cause and cuts a lot of pointless wakeup churn.

2. Attach an 'error' handler so any future unopenable node degrades to "no live reindex" instead of taking Pulse down. The comment in the existing catch already says watching is best-effort; this makes that true.

The same async-error gap exists in user-index.ts, which watches USER_DIR with an identical try/catch, so it gets the same handler. Its initial scan has already built the index, so losing live updates is a soft degradation.

Verification

Linux, bun 1.3.13:

• Before — with a socket present under MEMORY/, Pulse crash-looped and /healthz never came up.
• After — starts clean, logs the watcher warning once when applicable, serves normally.
• No new typecheck errors in either file (baseline error counts identical before/after: wiki 15→15, user-index 18→18; those are module-resolution noise from checking files in isolation).

Notes

Both changes are independent — the narrowing prevents the crash, the handler survives it. If you would rather take only one, the handler alone is the minimal fix, though the broad watch root is the underlying cause.