Bug: Store Sorting inconsistencies with Turbo Mode (Lazy Records)

Input from Gemini 3 Pro:

✦ ### Architectural Decision: "Soft Hydration" for Turbo Mode Sorting

We analyzed the trade-off between Full Record Instantiation and Lazy Property Injection ("Soft Hydration") for sorting in Turbo Mode (autoInitRecords: false).

The Problem: Neo.collection.Base#doSort uses direct property access (item[prop]). In Turbo Mode, items are raw JSON. If sorting by a Model-only field (calculated or mapped), the sort fails because the property doesn't exist on the raw object.

The Solution: We will implement "Soft Hydration" in Neo.data.Store#doSort. Before sorting, the Store will ensure that the sort field exists on the raw item. If missing, it will calculate/resolve the value using the Model definition and cache it on the raw object.

Why this wins:

1. Memory: Raw objects + a few cached properties are significantly lighter than 100k full Class instances. Full instantiation hits a browser memory wall for large datasets.
2. Latency: Full instantiation causes a massive initial UI freeze. Soft Hydration is "pay-as-you-go" and amortizes the cost.
3. Caching: By writing the resolved value back to the raw object, subsequent sorts on the same field become O(1) lookups, matching the performance of instantiated records.

Implementation Plan:

1. Override doSort in Neo.data.Store.
2. Iterate items and check for the sort property.
3. If missing, invoke a helper (e.g., RecordFactory.resolveValue) to compute and assign it.
4. Proceed with standard Collection sort.

Input from Gemini 3 Pro:

✦ I have implemented the "Soft Hydration" strategy to fix sorting in Turbo Mode (autoInitRecords: false).

Core Changes:

1. Neo.data.Store#doSort Override: When sorting in Turbo Mode, the store now iterates the raw items and "soft hydrates" them by resolving the sort property (using Model logic) and caching it directly on the raw object. This ensures subsequent sorts are O(1).
2. Neo.data.Store#resolveField: Added a helper to resolve fields (Mapping, Calculate, Convert) from raw data.
3. Model Hardening: Updated Contributor.mjs total_commits calculation to be "Turbo-Safe". It now polymorphically checks for either the canonical name (commits_array) OR the raw key (cy), ensuring it works in both Record and Raw contexts.

Documentation: Added comprehensive JSDoc to resolveField and the Model explaining the "Soft Hydration" architecture and its limitations (recursive dependencies must be handled manually in the model).

Result: Sorting by "Commits Only" (which uses the calculated total_commits field) now works correctly even when records are not instantiated, preserving the performance benefits of Turbo Mode.