fix: ResolveBulk under root service lists/objects and nullable-nav keys - #539

Reviewed and pushed a follow-up commit (af5827a) with the administrative fixes and the two duplication nits — the behaviour changes are untouched. Suites are green on that head: core 1140 (net9 + net8), EF 47, AspNet 92.

What I changed

• 6.1.4, not 6.1.3. 6.1.3 is released, so your two entries moved to a new # 6.1.4 section and PackageVersion is bumped in both csproj files. I also reverted the edits to the 6.1.2/6.1.3 entries — those releases shipped the per-item fallback, so their notes should keep describing that; the new behaviour is described in the new section.
• Deduplicated the bulk key selector rebind. It was the same 8 lines in ReplaceContext and BuildBulkKeySelection → ExpressionUtil.RebindBulkKeySelectorParameter.
• Deduplicated the "already built in the first pass" check. It was duplicated verbatim in FilterExpressionExtension and SortExtension → BaseFieldExtension.CollectionBuiltInFirstPass. That one is a subtle heuristic, and two copies of it would have drifted.
• Dropped the formatting-only changes (IsSelectedOnToSingleNode, ValidateFieldsCanMerge, the keys Concat ternary, and the object initialisers in ServiceBackedCollectionExtensionsTests) so the diff is only behaviour. Worth checking your csharpier version against CI's, since it clearly disagrees with what's on main.

Verification beyond your tests — two shapes I probed on your branch, both pass, so no action needed; noting them so you know they're covered:

• a root service list and a root service object where every selected sub-field is a service field, so the first pass has nothing of its own to select → one bulk call, correct data
• a root service field whose service returns null → no NRE, null/empty propagates (this one seemed most at risk given first-pass materialisation is new)

The design question, which is the one thing still open. Every root service list/object now takes the two-pass path whether or not anything below it has a bulk resolver — an extra expression compile plus an intermediate projection for a shape that used to run in one pass. Your original PR description raised exactly this and it's still unanswered:

Review whether always running the two-pass path for root service lists (even without nested bulk) is acceptable, vs opting in only when bulk resolvers are present

Two sub-questions I'd want settled before this merges:

1. Is the unconditional cost measured? If a root service list with no bulk fields below it is now measurably slower, gating on "are there bulk resolvers at or below this node?" is cheap — the document already knows its own shape at compile time (HasServicesAtOrBelow is the same kind of walk). If it's noise, unconditional is simpler and I'd keep it.
2. The timing change deserves a note. For these fields the service now runs during the first pass, so ExecuteServiceFieldsSeparately no longer means "services run after the context pass" for root service fields. Anything keyed off isFinal == false — a BeforeExecuting hook, debug timings — now sees services in pass one. Worth a line in the CHANGELOG entry even if we keep the behaviour.

No other blockers from me. One cosmetic thing I left alone deliberately: HardwareSensorStatusPageBulkTests carries domain names from the app (DetexyBoard, SerialOrExternalId). Good fidelity to the real failure, slightly odd in this repo long-term — your call whether to neutralise them.