grepai: fix index staleness, mandate usage, document config for new machines

Index was dead since 2026-04-19 (watcher not running). Fixes:
- Watcher restarted; scheduled task registered for login persistence
- Removed .md 0.6x penalty — markdown is primary content in this repo
- Added session-logs/ 1.3x, .claude/ 1.2x, /clients/ 1.1x relevance bonuses
- CLAUDE.md: grepai_search is now the first step for any context lookup
- OLLAMA.md: documents config overrides + watcher setup for new machines

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/OLLAMA.md

@@ -96,6 +96,37 @@ This keeps Claude tokens focused on reasoning, decisions, and execution. Ollama
 - Security decisions, auth review, production migrations
 - Final field values on API payloads (rates, IDs, quantities)
 
+### GrepAI config (re-apply on new machines)
+
+`.grepai/` is gitignored (90 MB index + machine-specific timestamps). After running `grepai init` on a new machine, apply these overrides to `.grepai/config.yaml`:
+
+**Remove the `.md` penalty** (markdown is primary content here, not docs noise):
+```yaml
+# DELETE this block:
+- pattern: .md
+  factor: 0.6
+```
+
+**Add these bonuses** under `search.boost.bonuses`:
+```yaml
+- pattern: session-logs/
+  factor: 1.3
+- pattern: .claude/
+  factor: 1.2
+- pattern: /clients/
+  factor: 1.1
+```
+
+**Start watcher + register scheduled task:**
+```bash
+D:/claudetools/grepai.exe watch --background
+# Then in PowerShell (admin not required):
+$action = New-ScheduledTaskAction -Execute "D:\claudetools\grepai.exe" -Argument "watch --background" -WorkingDirectory "D:\claudetools"
+$trigger = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
+$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Hours 0) -MultipleInstances IgnoreNew
+Register-ScheduledTask -TaskName "GrepAI Watcher - claudetools" -Action $action -Trigger $trigger -Settings $settings -Force
+```
+
 ### Warm-start and GrepAI
 
 GrepAI uses `nomic-embed-text` for context lookups, which keeps the Ollama **service** running continuously. The 30-50s service cold-start is effectively eliminated in normal workflow. `qwen3:14b` may take ~5s to swap into VRAM if it hasn't been called recently, but that's the worst case — not 50s.