restore-snapshot silently skips a node when the snapshot's git URL no longer matches the node list

# restore-snapshot silently skips a node when the snapshot's git URL no longer matches the node list, no error at all

I have a snapshot with this entry in `git_custom_nodes`:

```json
"https://github.com/WASasquatch/was-node-suite-comfyui.git": {
"hash": "ea935d1044ae5a26efa54ebeb18fe9020af49a45",
"disabled": false
}
```

That's the original author's repo. It still exists and clones fine on its own with a plain `git clone`. But `custom-node-list.json` doesn't point there anymore — it's now `https://github.com/ltdrdata/was-node-suite-comfyui` (id `was-ns`, the description even says it's the replacement pack after the original author retired).

When I run `restore-snapshot` on this snapshot, every other node in it (about 39) installs fine, each with the usual `Download: git clone '...'` + `Install: pip packages` output. This one node never gets a clone line, never prints an error, nothing — it just shows up at the very end as:

```
[ FAILED ] was-node-suite-comfyui
```

If I edit the snapshot to point at the `ltdrdata` fork instead (with the matching hash), the exact same restore-snapshot run installs it like any other node. So the repo itself was never the problem — the URL in the snapshot just doesn't match anything in the current node list anymore.

Happened the same way on three separate fresh instances, so it's consistent, not a fluke.

I dug into `restore_snapshot()` in `glob/manager_core.py` a bit. There's a loop that looks up each git URL in `unified_manager.repo_cnr_map`, and if it doesn't find a match (`cnr is None`), there's no `else` — it just moves on without installing, without erroring, and without marking it processed. From reading the code, I'd expect it to still fall through to the later loop that clones any leftover URL directly, but that doesn't seem to happen in practice — I couldn't fully trace why before the entry drops out. Might be something upstream in `reload()`/`get_custom_nodes()` that removes it earlier, not sure.

Either way, the real issue is that this fails completely silently. There's no way to tell from the output whether a node's install was attempted and failed, or just never looked at. Some kind of explicit message for the "couldn't resolve this URL to anything" case would've saved a lot of debugging time — I only found the actual cause by grepping the cached node list myself.

ComfyUI-Manager commit: f39cbd56fecae0b27a446c0cd450cd591f3a8bea

Start in glob/manager_core.py at restore_snapshot(), then trace unified_manager.repo_cnr_map and the reload()/get_custom_nodes() paths mentioned in the report. Reproduce with a snapshot containing the original WASasquatch URL and compare it with the ltdrdata URL. Done means an unresolved snapshot URL produces an explicit result instead of being silently skipped.

Written by the indexing model from the issue text.