fix(data-table): make selection actions ID-based

[IzumiSy]

Motivation

Follow the proposal on #604 to align selection actions with the new ID-based row-selection API.

Controlled selectedIds and defaultSelectedIds can include records the table has never loaded. The existing bulk-action contract derives eligibility, counts, disabled state, and execution payloads from available row objects. Consequently, visiting another page can change an action's apparent availability and target without changing selection or the underlying records. Actions without a predicate can also silently omit selected records from their payload.

Selection actions have not been released yet, so update their contract directly rather than preserve an incomplete row-based operation model.

Design Decision

Selection identity is the operation target

SelectionAction.onClick receives a fresh click-time snapshot of every selected ID, including unloaded IDs. Remove selection-action canApply, automatic eligible counts, and row-availability-based disabling. Consumers own eligibility checks, required fetching, confirmation UI, and execution; backend validation remains authoritative.

selectedRows remains available as a partial cache, but is not used to determine bulk-operation targets. Row actions retain canApply, since each operates on a concrete loaded row. DataTableAction now shares presentation only; it and SelectionAction no longer need a row generic.

Consumers update selection from actual results

Remove automatic selection clearing and keepSelection. Neither success nor failure changes selection implicitly. Controlled consumers remove only successfully processed IDs from their current selection, preserving ineligible records and selections made after a confirmation dialog opened.

Retain promise-based pending tracking, including helpers.run for work started later by a consumer-owned dialog, to preserve busy feedback and prevent overlapping bar actions. Explicit Clear and helpers.clearSelection remain intentional full-selection commands. No new confirmation component or execution API is introduced.

Summary

• Dispatch complete, isolated ID snapshots from both inline and overflow selection actions, independently of row-cache availability.
• Keep row-level eligibility and existing pending/accessibility behavior while removing implicit bulk eligibility and selection cleanup.
• Migrate consumer examples to explicit eligibility and result-based selection updates, with regression coverage for unloaded IDs, snapshot isolation, and partial success.
• Update authored documentation and the pending bulk-actions minor changeset, regenerate docs and the consumer skill, and record the revised operation contract in the existing decision.