[derechopiano]

PivotTable fields can currently be added by checkbox and moved by menu, but cannot be dragged between areas. This adds source-field drops, assigned-field moves between Filters, Columns, Rows and Values, and reordering with an insertion line. The floating drag caption remains wide enough to read ordinary field names.

Drops use the existing pivot.addField, pivot.moveField and pivot.removeField commands. Duplicate Values summaries are identified by their captions, so reordering preserves the exact summary and its settings. Escape cancels, no-op drops avoid undo entries, and dragging an assigned field outside the pane removes that instance. Area lists scroll during a held drag near their edges. Existing menus and checkbox clicks remain available.

This implements the dragging listed as follow-up work in #474 and #498. It also preserves upstream's newer Σ Values field: the virtual field appears with multiple summaries, moves between Rows and Columns, and cannot be dropped into Filters or Values or removed outside the pane. Visual slots are mapped to engine positions so the virtual field and hidden report-filter entries do not shift ordinary field indices. Upstream's translated menus and responsive pane styling are retained.

Verification

• 21 pointer-driven integration tests pass, including all 12 ordinary cross-area directions, duplicate summaries, cancellation, undo, scrolling, Σ Values movement and invalid drops, and dragging an ordinary row across Σ Values. Two additional unit tests cover visual-to-engine index mapping, including hidden report filters. An engine regression test verifies atomic updates and rollback for invalid drop positions. The new pointer tests cover source and cross-area drops immediately after Σ Values, with single-step Undo and Redo; the corrected pane was also rendered and inspected.
• The contributor manually tested the earlier development build on Windows with a trackpad: moves both ways, repeated Sales summaries, insertion-line ordering, Escape/whitespace cancellation, outside removal and Undo, menu/checkbox clicks, smaller-window scrolling, and Σ Values placement passed. The resolved merge was verified by automated tests; it has not had a separate manual desktop pass.
• Ordinary worksheet PivotTable behavior was compared with Windows Excel using synthetic data. Excel checks confirmed Rows/Columns movement, duplicate Values additions, Escape cancellation and an ordering indicator. References: Field List and layout.
• cargo xtask ci passed all eight gates on Windows for the atomic-drop update: formatting, Clippy with warnings denied, full workspace tests, assets, layers, WebAssembly, parity, and keytips. GitHub CI will rerun for this update.

Remaining scope

OLAP arrangements and new settings dialogs are outside this change.

Code and tests were developed with Codex assistance; the contributor performed the manual Excel and development-build trackpad checks.

Closes #988

Related implementation

#1781 independently implements overlapping field dragging. Comparing it exposed a drop immediately after Σ Values that this PR did not place correctly. The existing pivot.addField and pivot.moveField commands now accept an optional final valuesPosition, applied in the same transaction as the ordinary field move. This preserves the indicated order with one report refresh and one Undo step. Existing callers retain their behaviour. Coordination is in #1781 (comment).

[FredApps]

I read the engine change (valuesPosition on pivot.addField and pivot.moveField, applied in the same update so one refresh and one Undo step) and its validation test, and went through the 21 pointer tests and the pane's visual-to-engine index mapping. I found no defect, and the test count in the description matches the source (21 integration tests, 2 unit tests, 1 engine test). I am not approving because the description leaves two points open that a maintainer should decide.

Questions for a maintainer:

1. #1781 (PivotTable Fields pane: drag and drop fields between areas) is open and, as the description says, independently implements overlapping field dragging. Both change pivot_pane.rs and would conflict. Which of the two should land, or should they be combined?
2. The description says the resolved merge with upstream's Σ Values changes "has not had a separate manual desktop pass", and the Excel comparison was on ordinary worksheet PivotTables only. Is automated coverage enough for the Σ Values drop cases, or should someone do a manual pass first?

Validation: source reading plus the hosted check "cargo xtask ci", which passed on this head (3e2a1f9). No local tests were run (builds are paused).