Add an ingest_vue_components_manifest to resolve unplugin-vue-components auto-imports into the graph

[Estheisia]

What problem does this solve?

Vue projects using unplugin-vue-components never write an import statement for components used in templates, the plugin injects the resolution at build time
Static analysis has no way to know that <SomeComponent> in Home.vue's template resolves to src/components/SomeComponent.vue, so search_code/query_graph/trace_path can't trace template

unplugin-vue-components already computes this exact resolution and can dump it as a JSON manifest via its dumpComponentsInfo option (merged upstream, unplugin/unplugin-vue-components#830):

// .components-info.json
[
  // Standard component
  { "name": "default", "as": "SomeComponent", "from": "/abs/path/src/components/SomeComponent.vue" },
  { ... },

  // VueRouter specific
  {
    "from": "vue-router",
    "name": "RouterView",
    "as": "RouterView"
  },
  {
    "from": "vue-router",
    "name": "RouterLink",
    "as": "RouterLink"
  }
]

This is structurally identical to the dbt target/manifest.json case already solved by ingest_dbt_manifest (#576 / PR #583

Proposed solution

Add an opt-in MCP tool, following the ingest_dbt_manifest pattern:

ingest_vue_components_manifest { project, manifest_path }

• Runs post-index_repository against an existing store — augments, doesn't fabricate.
• Reads the {name, as, from}[] manifest.
• For each entry, resolve as (the template tag name) against existing template-usage sites already extracted from .vue files, and add an IMPORTS edge from the usage site to the from file's Module/File node.
• No schema change needed, reuses cbm_store_upsert_node / cbm_store_insert_edge and the existing IMPORTS edge type, same as ingest_dbt_manifest reuses DEPENDS_ON

Alternatives considered

Parse components.d.ts (the dts output) instead : it also lists all resolved components, so it needs no extra plugin option

Rejected because it requires a bespoke TS-declaration parser vs flat JSON, and dumpComponentsInfo is the format the plugin author explicitly built for external tool consumption

Confirmations

• I searched existing issues and this is not a duplicate.

[DeusData]

Thanks for the Vue auto-import manifest proposal. Triage: parsing/quality feature backlog under #592.

This is a sensible way to make build-time component resolution visible to the graph without guessing from templates. A future implementation should treat the manifest as an explicit local input, validate paths stay inside the project, and define how stale manifests are detected.