Clean up NodeDefinition typing, fix empty-input handling, expose ClusterSummaryFeatures

[sevmag]

Summary

First in a series of small PRs being carved out of #813 to make review easier (see the comment on #813 for the full split plan). This one is all the touch-ups around NodeDefinition that landed in that branch and aren't tied to the CNN work — pulling them out so they can be reviewed and merged on their own.

Three independent commits:

1. Clean up typing and docstrings in NodeDefinition — replace lowercase torch.tensor annotations with torch.Tensor; fix return-type docstrings on forward and _construct_nodes (they return a tensor, not a graph); correct ClusterSummaryFeatures._construct_nodes return annotation from Data to torch.Tensor; fix _verify_standardization annotation (returns None, not torch.Tensor); reorder imports to project convention; clarify the ClusterSummaryFeatures docstring about which features come from Glauch's thesis and which (counts) don't.
2. Fix NodeAsDOMTimeSeries empty-input handling — when the input pulse tensor is empty, _construct_nodes previously returned a torch_geometric.data.Data built from np.column_stack([x, []]) instead of a tensor of shape [0, num_features]. Downstream callers expect a tensor; this could crash or silently produce a malformed graph. Returns a correctly-shaped empty tensor and drops the now-unused Data import.
3. Export ClusterSummaryFeatures from the top-level data_representation package (was already reachable via .graphs).

No functional changes outside of (2), which is a bug fix.

Test plan

• CI green
• pre-commit run --files src/graphnet/models/data_representation/graphs/nodes/nodes.py src/graphnet/models/data_representation/__init__.py — already verified locally

Split from #813.

🤖 Generated with Claude Code

[Aske-Rosted]

This looks good to me as long as there is a reason for why you might want to allow the passing of empty data objects. I would assume that we in that case might just want to catch that instance and raise an error?

[sevmag]

This looks good to me as long as there is a reason for why you might want to allow the passing of empty data objects. I would assume that we in that case might just want to catch that instance and raise an error?

Good point! I agree that an empty graph is probably not what we want. I will adjust it to throw an error.

[Aske-Rosted]

Looks good to me.

Just realised one of the tests is now failing. I guess we have been doing a dummy test with an empty data object.

[Aske-Rosted]

https://github.com/graphnet-team/graphnet/blob/main/src/graphnet/datasets/test_dataset.py#L10

It seems like event 5 in the ERDA hosted dataset is empty. So we actually have to consider how we handle that in a way where this test still passes.

I think it's probably appropriate to raise a warning instead of an error and then leave it at that. That will at least inform the user if they have empty events in their input.

[sevmag]

I agree!