[Feature]: Dart part files should keep their own file node (linked to the library), not vanish from the graph #4008

Problem or use case

A Dart part of file has no node of its own in the graph. Since #1098 the extractor redirects the part's declarations to the parent library (good - one library, one id namespace), but it also drops the part's file node entirely (test_roadmap_bug_fixes asserts "No child file node should be created").

As a result a real, scanned source file cannot be looked up by name:

$ graphify explain "bg_account_runtime.dart"
No node matching 'bg_account_runtime.dart' found.

path cannot start from or reach it either. In Flutter apps parts are commonly used to split one large library across several big files (in our app: a 2,500-line part of 'background_service_entry.dart' and four part of 'mail_dao.dart' files), so these are exactly the files an assistant wants to ask about before reading them. Today the only way is to know which library owns the part and ask about the library instead.

Proposed solution

Keep the redirect, but keep the part's file node too:

• the part gets its regular file node (id from its own path, label = file name, source_file = the part);
• library --includes--> part, anchored on the part of line;
• part --contains--> declaration for every declaration the library defines from this part.

Declaration ids stay in the library's namespace and the library's defines edges are unchanged, so the split that #1098 fixed does not come back. explain "<part>.dart" then lists the part's declarations and its library.

Alternatives considered

• Status quo + documenting "ask the parent library": works, but every consumer has to know the part of structure in advance.
• Moving defines from the library to the part: would re-split the library's namespace and break the redirect contract, so no.

Area

Extraction or language support

Are you willing to submit a PR?

Yes, I can work on this

Compatibility / behavior impact

• Node/edge ids: no existing id changes. Adds one file node per part file plus includes and contains edges.
• graph.json schema / cache semantics: unchanged (includes is already used by the Blade extractor). Existing graphs pick the new nodes up on the next rebuild.
• test_roadmap_bug_fixes currently asserts the part has no node; that assertion has to flip to "the part has its own node, its declarations are still defined by the library".

Additional context

Found together with #4002 on a ~300-file Flutter app (graphify 0.9.73; the extractor is unchanged on v8 @ e10df08 / 0.9.74).