Query the current aggregation bucket

[isum]

This PR adds support for querying the current, partially filled aggregation bucket with GraphQL.

How does it work?

When the current: include is specified in the GraphQL request for an aggregation, the graph-node loads the most recent time series entities that do not currently form a complete bucket and calculates the aggregates on the fly. Then, the results are merged with the relevant complete buckets to produce one response list.

[lutter]

Nice! This will be very useful.

Some comments from Claude - not entirely convinced they are necessary; feel free to address or ignore before merging:

3. nested_current_include_count test is redundant

 File: aggregation.rs

 This test verifies the exact same thing as nested_current_include (6 total rows, 3 per token). It provides no additional signal. Consider replacing it with a more useful test — e.g., testing pagination (first/skip) with current: include, or testing what happens
 when the current argument is omitted.

 4. Missing test coverage for key scenarios

 File: aggregation.rs, runner_tests.rs

 - current argument omission: No test verifies that omitting current defaults to exclude behavior through the full GraphQL → store path. The unwrap_or_default() in prefetch.rs handles this, but it's not tested end-to-end.
 - first/last with multiple data points in current bucket: Store tests have only 1 data point per token in the current bucket, so first == last trivially. The runner test checks sum only.
 - Empty current bucket (all data rolled up, no new data): Not tested — does current: include gracefully return the same as exclude?
 - Error paths: The NotSupported error for AttributeNames::All and the ParentLink rejection are untested.

 5. max_num_rows() could theoretically overflow

 File: relational_queries.rs

 fn max_num_rows(&self) -> u32 {
     self.range.0.first.unwrap_or(EntityRange::FIRST) + self.range.0.skip
 }

 If both first and skip are near u32::MAX, this overflows. In practice the values are small (default first=100), but saturating_add would be defensive. 

[lutter]

It might be good to make sure the split results in exactly 2 components (maybe as a debug_assert!) Or, the select_current_sql could be stored pre-split as (String, String)