Use display_name tag for @config.when nodes in visualizations

[digit50]

closes #1761

Nodes built from @config.when or @config.when_not functions ignored their display_name tag in visualizations. create_graphviz_graph rebuilt their label as f"{n.name}: {config_key}" and passed it as the explicit name to _get_node_label, which gives that argument priority over the tag, so these nodes always showed as a: mode instead of Pretty A: mode.

Changes

• hamilton/graph.py: moved the display_name tag lookup (including the existing "list means first element" handling) out of _get_node_label into a small _get_display_name helper inside create_graphviz_graph. _get_node_label uses it when no explicit name is given, as before.
• The config-node label is now built as f"{_get_display_name(n)}: {config_key}", so the tag is used and the config suffix is kept. Nodes without the tag still get <node name>: <config keys>.

How I tested this

• Added test_create_graphviz_graph_display_name_on_config_nodes in tests/test_graph.py. It builds a graph from a @config.when function with @tag(display_name=...) on the outside and a @config.when_not function with the tag on the inside, and asserts that the Digraph source contains <b>Pretty A: mode</b> and <b>Pretty C: mode</b> and no longer contains <b>a: mode</b> or <b>c: mode</b>. It fails on main and passes with this change.
• Ran tests/test_graph.py, tests/function_modifiers and tests/plugins/test_polars*.py before and after the change. The only failures are the same on both sides and come from my local environment (no Graphviz dot binary for the render tests, polars 2.x and a missing xlsxwriter for the polars plugin tests).
• Ran the reproduction script from the issue: display_all_functions() and visualize_execution() now both show Pretty A: mode, Pretty C: mode and Pretty D.
• ruff check and ruff format --check pass on the changed files.

Notes

No change to the explicit name override in _get_node_label; it still takes priority over the tag, so materializer and other callers behave as before.

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.