affected/reverse-dep false negatives; god_nodes not a CLI subcommand; --output flag ignored on extract (v0.9.18, Windows)

[katha-begin]

Version: graphify 0.9.18 (installed via uv tool install "graphifyy[anthropic,mcp]==0.9.18")
OS: Windows 11 (Git Bash / MSYS shell)

1. affected (and reverse-dep lookups generally) return false negatives when queried by the scanned-file node name

When file A imports a symbol from file B via from pkg.sub.mod import X, the resulting imports_from edge's target is an ID derived from the import string itself (dots → underscores, e.g. pkg_sub_mod), not the ID of the actual scanned node for mod.py (which may have a different prefix depending on how the corpus root was passed to extract, e.g. sub_mod or code_sub_mod).

Repro:

graphify affected "mod.py" --graph graph.json            # -> "No affected nodes found." (false negative)
graphify affected "sub_mod" --graph graph.json            # -> also fails (real scanned-node id)
graphify affected "pkg_sub_mod" --graph graph.json        # -> works (import-string-derived id)

graphify diagnose multigraph --graph graph.json --json shows a large dangling_endpoint_edges count (thousands, on a ~21k-node/~49k-edge corpus), consistent with these import-string-derived target IDs never resolving to a real node.

This is reproducible identically whether the corpus is extracted in-place from its real package root or from a staged/copied directory tree — it is not a staging artifact, it's the import-target ID resolution itself.

Impact: any downstream tool/agent that calls affected "<file-or-symbol-name>" expecting it to "just work" (the natural first guess) silently gets zero results instead of an error, which reads as "nothing depends on this" rather than "wrong ID format."

Suggested fix: either (a) deduplicate/alias the import-string-derived node ID to the real scanned node when the import resolves to a file that's actually in the corpus, or (b) have affected do fuzzy/label matching (like explain/query already do) before falling back to exact-ID lookup, or (c) document the ID-format requirement prominently next to the affected command help text.

2. god_nodes is documented as a capability but is not a CLI subcommand in 0.9.18

The MCP server (graphify-mcp) exposes a god_nodes tool (confirmed via session.list_tools() over the stdio transport), and the README's benchmarks table references "God nodes" as a core capability, but graphify --help has no god_nodes (or similar) subcommand — it's only reachable via the MCP interface. Either add a CLI equivalent (graphify god-nodes --graph ...) or note in --help/README that it's MCP-only.

3. --output flag on extract is silently ignored (use --out instead)

graphify extract <path> --output <dir> does not write to <dir> — it silently falls back to the default <path>/graphify-out/. The correct flag (confirmed via graphify --help) is --out <dir>. Since --output doesn't error, it's easy to assume it worked and then not find the output where expected. Suggest either supporting --output as an alias or erroring on unrecognized flags instead of silently ignoring them.

Happy to share a minimal repro corpus if useful — kept this report generic/non-proprietary since it came out of an internal pilot on a private codebase.