feat(data-editor): add keepFocusOnEnterAccept prop

[wilsonglasser]

Summary

Adds a new keepFocusOnEnterAccept boolean prop to DataEditor. When enabled, pressing Enter to commit an overlay edit keeps the cursor on the edited cell instead of moving it down by one row.

The other accept directions are unaffected: Tab, Shift+Tab, and Shift+Enter continue to move horizontally / upward as usual. Only the [0, 1] (Enter → down) movement is neutralized.

Motivation

In spreadsheet-style data editors backing real databases, a deliberate Enter generally means "commit this edit" - not "move the cursor down". The default Enter-moves-down behavior makes single-cell edits feel like the cursor is being yanked away after every commit, and it interferes with subsequent arrow-key navigation. This is also the behavior most native editors (Excel-style or otherwise) expose as a configuration option.

Implementation

The change is localized to onFinishEditing in packages/core/src/data-editor/data-editor.tsx. When keepFocusOnEnterAccept is true and the incoming movement is exactly [0, 1], we replace it with [0, 0] before the rest of the handler runs - so updateSelectedCell is never invoked for the Enter case and the cursor / scroll stay put. All other movement vectors flow through unchanged.

+ if (keepFocusOnEnterAccept && movement[0] === 0 && movement[1] === 1) {
+     movement = [0, 0];
+ }
  const [movX, movY] = movement;
  if (gridSelection.current !== undefined && (movX !== 0 || movY !== 0)) {
      ...
      updateSelectedCell(...);
  }

Backwards compatibility

Default is false, so existing consumers see no behavior change. Opt-in only.

Test plan

• Verify Enter on an open overlay still commits the value when keepFocusOnEnterAccept={true}.
• Verify the cursor stays on the edited cell after Enter.
• Verify Tab / Shift+Tab / Shift+Enter still move in their respective directions.
• Verify Escape still cancels without movement.
• Verify default behavior (keepFocusOnEnterAccept unset or false) is identical to today's.