feat(mcp): surface template-view callers in explore blast radius

[Johnny-Tsai]

What

In the codegraph_explore blast-radius section, list template-view callers (.cshtml / .razor / .vue / .svelte / .astro) in their own slot instead of letting them compete with same-language code callers under a single flat cap.

Why

Caller files were listed under one FILE_CAP (4) before +N more. Template views are cross-layer callers — a change to a JS/TS helper ripples into the views that use it — but they're typically far fewer than the same-language code callers, so they got drowned out and vanished into +N more.

Concretely: a JS helper used by 4 .js files and 22 .cshtml views would render 0 views, hiding the answer to "which views depend on this?". This showed up on a real .NET MVC ERP, where view callers of shared JS helpers are exactly what you need to see before editing.

How

Split nonTest callers into viewFiles (by extension) and codeFiles, each capped independently. Code callers keep the existing in … phrasing; views get an appended ; N view(s): … slot. Pure side-by-side display change — no graph/edge changes.

Testing

Added a case to explore-blast-radius.test.ts: a helper with more than FILE_CAP code callers plus a .vue view now surfaces the view in its own dedicated slot rather than burying it behind the code-caller +N more. Existing blast-radius tests still pass.

Note: the most natural fixture would use a .cshtml view calling JS from an inline <script>, which depends on the Razor <script> indexing in #959. This PR uses .vue (already supported) to keep it self-contained; the same display path covers .cshtml once #959 lands.

🤖 Generated with Claude Code