Refresh the AI index after a pull that changed tracked files

AI_INDEX_ON_PULL was designed, defaulted false, and never read by anything —
so nothing has ever rebuilt the index automatically. A pull is the only thing
that changes tracked files on a server, which makes it the only moment the
index can go stale, and a timer would do nothing 23 times a day while still
drifting from the pull that matters.

Staleness is invisible in the answers: the index keeps returning the old text
with confident, correct-looking citations. Gated on pull success, on
AI_INDEX_ON_PULL and on AI_ENABLED, and never fatal — a git pull must not fail
because an embedding call timed out.

Deployment/master.conf.template

@@ -1622,7 +1622,11 @@
 # walk — an embedded secret cannot be rotated out of a vector.
     AI_INDEX_DB="$DATA_DIR/ai_index.db"
     AI_INDEX_BATCH=32               # chunks per embed request
-    AI_INDEX_ON_PULL=false          # re-index after a successful git pull once AI is in use
+# A pull is the only thing that changes tracked files on a server, so it is the only moment the
+# index can go stale — and staleness is invisible in the answers, which keep citing the old
+# text with full confidence. Incremental: unchanged files are skipped, a no-op run is ~66ms.
+# Also gated on AI_ENABLED, and ai_index.sh refuses on its own unless that is true.
+    AI_INDEX_ON_PULL=true           # re-index after a git pull that changed tracked files
     AI_SEARCH_K=8                   # chunks retrieved per query
     AI_SEARCH_PER_FILE=3            # cap per file so one document cannot fill the context