DevIndex: Add Contextual Rank Column to Grid

Input from Gemini 3.1 Pro:

✦ ### Architectural Post-Mortem

This issue started as a straightforward task to replace the Grid's index column with a rank column but evolved into a deep dive into the performance mechanics of Neo.mjs's "Turbo Mode" and VDOM rendering.

The Challenge: We needed a contextual rank that recalculated based on "Structural" filters (e.g., Country) but remained static during "Search" filters (e.g., Username) and grid sorting.

The Evolution of the Implementation:

1. Naive Override (Failed): We initially tried overriding Store:filter() to calculate the rank on the fly. This was rejected because executing an O(N) calculation on 50,000 records on every keystroke during a text search is a performance disaster.
2. Cached Override with setSilent (Buggy UI): We added a needsCalculation cache hash so the heavy lifting only occurred when Structural filters changed. To avoid an event storm (50k recordChange events), we used record.setSilent({ rank: X }).
   • The Flaw: setSilent increments the Record's version, but if the array length and structure don't change (e.g., filtering a 1-row view to a 1-row view), the Grid's rendering engine might not visually update the row if the reference remains identical and the event is swallowed. The DOM became stale.
3. The "Map + Renderer" Pivot (Abandoned): We tried decoupling the rank from the Record entirely by storing it in a Map and using a Grid column renderer.
   • The Flaw: This broke reactivity entirely. If the Record itself doesn't change, the Grid row is never re-rendered, meaning the renderer is never called to fetch the new Map value.
4. The Final Architecture (Post-Filter Analysis): The breakthrough was realizing we need to know the exact visibility state of the records before deciding how to mutate them. We enhanced the framework base classes (Neo.collection.Base and Neo.data.Store) by adding a silent parameter to their filter() methods.

The Final Workflow (DevIndex.store.Contributors):

1. We intercept filter().
2. We calculate the new ranks into a temporary newRanks Map.
3. We execute super.filter(silent: true). This builds the final me._items (the visible rows) without triggering the Grid.
4. We iterate the newRanks Map:
   • If the item is a raw object, we mutate it directly (silent by nature).
   • If the item is a Record AND it is in the me._items visible subset, we execute a loud update (item.rank = X). This fires recordChange specifically for the visible rows, guaranteeing the Grid's VDOM updates the DOM immediately.
   • If the item is a Record but is HIDDEN, we execute item.setSilent({ rank: X }). This prevents the dreaded 50k event storm while keeping the data accurate for when the row eventually scrolls into view.
5. Finally, we manually fire the Store's filter event.

This architecture elegantly solves the "Stale UI vs. Event Storm" dilemma in high-performance virtualized grids.