feat: expose memory-to-snapshot fallback in search output

[ktappdev]

Problem

contexting search-hints --memory (default: true) tries to connect to a live watch server. When watch isn't running, it silently falls back to reading the snapshot from .ctx/ctx_index.json. No indication in the output that fallback happened.

This matters because:

• Snapshot may be stale (hours/days old)
• Agent thinks it's getting live data but it's not
• No way to know if watch is running without separate check

Proposed Solution

Add "fallback": true to JSON output when memory search was requested but snapshot was used:

{
  "source": "snapshot",
  "fallback": true,
  "results": [...]
}

When memory search succeeds: "fallback": false or field omitted.
When --memory=false: "fallback" field omitted entirely.

Implementation Notes

• Already tracking usedMemory bool in command_search.go:84
• Map to output: usedMemory=true → "source": "memory", usedMemory=false → "source": "snapshot", "fallback": true
• QueryMemorySearch returns error on connection failure — that's the fallback trigger
• Covered by envelope approach in feat: expose index freshness metadata in search results #2 (source field), but fallback is explicit signal

Acceptance Criteria

• "fallback": true present in JSON when memory search fails and snapshot used
• "fallback": false or absent when memory search succeeds
• Works with --memory-only (errors instead of fallback, no fallback field)
• Non-JSON output: print [fallback] prefix or similar indicator