[Bug]:merged graph — ambiguity refusal reports cross-repo same-basename nodes as being in one file #4512

**Colliding basenames — the broken case:**

$ graphify explain "Config" --graph m/graph.json
Ambiguous: 'Config' matches 2 nodes in dup.py.
  L1
    id: web::dup_config
  L1
    id: ml::dup_config
Retry with the full node id.
$ echo $?
3


$ graphify path "Config" "Config" --graph m/graph.json
Ambiguous: 'Config' matches 2 nodes in dup.py.
  L1
    id: web::dup_config
  L1
    id: ml::dup_config
Retry with the full node id.
$ echo $?
3

Problems with that output, in order of severity:
1. **`in dup.py` is wrong** — there are two `dup.py`, in different repositories.
2. **The listing shows only `L1`** for both, so a reader cannot tell the candidates apart at all; the `web::` / `ml::` prefix in the `id` is the only distinguishing information present.
3. **It falls into the same-file form of the message**, `Retry with the full node id.` — which is *less* actionable than the cross-file form's `Retry with path::symbol ...`, and the `path::symbol` form is the one that actually resolves it here.
**Distinct relative paths — the correct case (unchanged behavior):**

$ graphify explain "Config"                      # pkg/a.py + pkg/sub/b.py in one repo
Ambiguous: 'Config' matches 2 nodes in different files.
  pkg/a.py
    id: pkg_a_config
  pkg/sub/b.py
    id: pkg_sub_b_config
Retry with path::symbol using one of the paths above (e.g. <path>::Config) or the full node id.

## Likely cause
`serve._resolve_single_node` appears to decide same-file vs cross-file from `source_file` alone, and `source_file` is repo-relative and unprefixed in a merged graph — so two nodes from different repos compare equal and take the same-file branch:

def _same_file_ambiguity_message(G, label, hits):
    source = G.nodes[hits[0]].get("source_file")        # 'dup.py' for both nodes
    where = f"in {source}" if source else "with no source file"
    listing = "\n".join(
        f"  {G.nodes[h].get('source_location') or G.nodes[h].get('label', h)}\n    id: {h}"
        for h in hits
    )

Note the listing uses `source_location` (line only) for the same-file branch, which is reasonable when the file really is shared — that assumption is what breaks here.
The information needed to fix it is already on the nodes: a `repo` attribute is present on merged nodes (`"repo": "web"` / `"repo": "ml"`, next to `local_id`), and it is absent/`None` for a single-repo build.
Possible directions (your call on which fits):
- treat `(repo, source_file)` as the file identity when deciding same-file vs cross-file, so this case takes the existing cross-file branch and its `path::symbol` hint; or
- keep the branch but render repo-qualified paths (`web/dup.py` / `ml/dup.py`) in both the `where` clause and the listing.
Either way, `web::dup_config` and `ml::dup_config` should not both render as bare `L1`.
Non-goal: this is unrelated to the `explain` resolution policy in #1969 — resolution correctly refuses here; only the message loses information.