erlang_callgraph.json records an ELP run that never happened

[Dshuishui]

Summary

Running the pipeline on a project with no Erlang sources — on a machine where elp
is not installed — leaves this behind:

<proj>/.codegraph/erlang_callgraph.json
{
  "status": "success",
  "backend": "elp",
  "elp_command": ["elp", "server"],
  "functions": [],
  "edges": []
}

command -v elp returns nothing; ELP was never started. Two problems:

1. The record contradicts what happened. Anyone reading it concludes "ELP ran
   fine, this project genuinely has no Erlang functions", when the truth is "the
   project has no .erl files, ELP was never consulted". The case where telling
   those apart matters is exactly when ELP is installed but failing — and the file
   reads identically then.
2. It is written into another tool's directory. The output path
   <proj>/.codegraph/ is codegraph's own data directory, so even a project that
   does not use codegraph at all gets one created for it.

Observed in every project run this way, Python and C++ alike — the language of the
project is irrelevant.

Why

batch_extract_all calls batch_extract for every registered language, so a
project with no Erlang sources still reaches the Erlang backend.
_analyze_project_uncached finds no .erl files and returns an empty result
without starting ELP — but _persist_analysis is called unconditionally from
_analyze_project, and it hardcodes "status": "success" and "backend": "elp".

Its docstring reads "Persist successful ELP output for diagnostics": it was written
for the success path, and sits where every outcome passes through.

Expected

1. Do not write the file when there are no .erl files — or write it with a
   status that separates no_erlang_sources / backend_unavailable / success,
   leaving backend and elp_command unset when ELP was never invoked.
2. Write it under fm_agent/ instead.