Improve context lookup for code-like source strings

[Lee-take]

Summary

• add a source-text fallback inside context lookup for code-like string literals/config keys such as deepseek-r1
• map source-text hits back to the smallest enclosing indexed symbol so context still returns implementation nodes instead of raw grep output
• deprioritize likely test/spec nodes for non-test queries and add coverage for string-alias lookup
• preserve exact code-symbol intent: specific queried symbols such as env_var_for now outrank broader source-text matches, while generic lowercase words such as message are not over-boosted

Why

codegraph_context could miss important implementation code when the user query named a code-like string that appears only inside function bodies, provider aliases, feature flags, event names, or route keys. In that case the existing node-name FTS path may return generic symbols or nothing useful, even though the indexed source contains an exact match.

This keeps the existing tool flow intact: agents still call codegraph_context, but the context builder can use exact code-like source text as an additional high-signal entry point.

Validation

• npx vitest run __tests__/context.test.ts — 22 passed
• npm run build — passed
• DeepSeek-TUI real-source validation after rebuilding dist/bin/codegraph.js: 7 function-specific context queries all ranked the expected function first:
  • normalize_model_for_provider — crates/config/src/lib.rs:1189
  • sanitize_thinking_mode_messages — crates/tui/src/client/chat.rs:1461
  • active_provider_has_env_api_key — crates/tui/src/config.rs:3464
  • env_for — crates/secrets/src/lib.rs:526
  • provider_env_vars — crates/cli/src/lib.rs:761
  • env_var_for — crates/tui/src/tui/provider_picker.rs:87
  • requires_reasoning_content — crates/tui/src/client/chat.rs:1591
• Also attempted npm test; local Windows run was blocked outside this change by MCP process tests failing to remove temp directories with EPERM plus a worker OOM after most tests had already passed.