Split Row And Column Context Menus

Goal: Allow ContextMenuPlugin to serve separate row and column menus through rowContextMenu and columnContextMenu while keeping one shared popup implementation. Column menus can also resolve different items for pinned column sections and individual columns.

Non-goals: Do not create a second plugin, duplicate popup rendering, or remove the older contextMenu fallback configuration in this change.

Expected behavior: Row targets use rowContextMenu; column header targets use columnContextMenu. If a row config is not provided, contextMenu remains a legacy row fallback. It can still be made shared by explicitly setting targetSelectors. Before opening, the active config can call resolve(context) to override or suppress the menu for the current target. Column context includes the column, virtual column index, and column section (rgCol, colPinStart, or colPinEnd).

API/config/data model: Add grid.rowContextMenu, grid.columnContextMenu, and kebab-case aliases. Keep grid.contextMenu as a legacy fallback. Keep additionalData.rowContextMenu compatibility for framework wrappers and add additionalData.columnContextMenu. ContextMenuConfig.resolve accepts a typed open context and returns a partial config, undefined for the base config, or null to skip opening.

Interactions/lifecycle: Right-click and optional left-click choose the config from the event target before opening. ROW_MENU_EVENT always resolves through row menu configuration. Menu item actions receive the active open context as context.menu, so actions can update the specific pinned or regular column that opened the menu.

Rendering/performance notes: Reuse the existing popup VNode and positioning logic; only switch the active menu config before refresh/open.

Edge cases: If a target-specific menu has no items, the popup still opens empty as before. Custom targetSelectors can override the default target selectors per menu. A resolver returning null prevents opening for that target.

Tests:

• Unit: No Pro unit test script exists in packages/pro/package.json; rely on type checking.
• E2E: Covered indirectly through demo build; browser-specific manual/E2E coverage can be added in packages/e2e/pro if desired.