Fix UseConnectionPaging on a nested EF collection - #576

Fixes #574.

Problem

UseConnectionPaging() on a field that isn't on the root query type failed when its collection comes from EF (e.g. a navigation property) with The LINQ expression 'edgeNode => ...' could not be translated. The collection is part of the parent's projection, so EF has to translate the paging, and it couldn't.

Changes

• Skip/Take: edges on a nested collection are paged with System.Linq's Skip/Take, the same as Fix UseOffsetPaging on a nested EF collection #573 did for offset paging.
• Cursors: ApplyCursors assigns cursors while it enumerates the page, and EF can't translate it inside a projection. For a nested collection the cursor is now selected as null, and ConnectionHelper.SetCursors fills it in once EF has materialised the edges (row skip + i + 1). EF runs a client method in the final projection when it gets a materialised collection.
• New extension hook: IFieldExtension.ProcessExpressionPostSelection lets an extension wrap a list field's projected result. It's a default interface method and a virtual on BaseFieldExtension, so existing extensions don't break.
• last without before: this read arguments.TotalCount, a single value for the whole request, so it can't work per parent. Each parent's page now comes from the end of its own collection via Reverse().Take(last), and the page is flipped back after it's materialised. Skip(Count() - last) doesn't work: EF puts the outer row into a correlated subquery inside the LEFT JOIN, which SQLite rejects (and other providers would need APPLY). Reverse() needs an ordered collection, but last has no defined meaning on an unordered one anyway.
• pageInfo { hasNextPage } alone: this called PageHasNext, which EF would have run in memory over the whole collection. It's now Skip(...).Any(), which translates to EXISTS.
• Shared edges field: every field that pages the same type shares one edges field (and one ConnectionEdgeExtension). The extension used the isQueryable of whichever field was configured first, so a root IQueryable connection plus a nested one of the same type failed (No generic method 'Skip' on type 'QueryableExtensions'). It's now decided each time from the expression. The constructor parameter is kept for API compatibility and no longer used.
• hasPreviousPage off by one: for last without before it was false when exactly one item comes before the page (e.g. last: 2 of 3). This affected root fields too.

Root field paging builds the same expressions as before. The only change on root fields is the hasPreviousPage fix. Nothing is breaking: public methods keep their signatures and the additions are new members.

Tests

• PagingTests (EF/SQLite), all with nested collections:
  • first with totalCount and pageInfo
  • an aliased cursor
  • after
  • per-parent last on two actors with different counts
  • last + before
  • root and nested paging of the same type in one query
• PagingSqlTests:
  • nested connection paging is a single query paged in SQL (ROW_NUMBER) with unused columns pruned, for both first/after and last
  • nested hasNextPage alone is EXISTS, with no COUNT
• PageInfoTests: the hasPreviousPage off-by-one.

Full suite passes on net8.0, net9.0 and net10.0.

Note: dotnet tool restore fails on main. .config/dotnet-tools.json lists the command dotnet-csharpier, but csharpier 1.0.0 names it csharpier. I formatted with dnx csharpier@1.0.0 and left the manifest alone.

🤖 Generated with Claude Code