[Bug(sp-dropzone)] sp-dropzone-drop event does not fire on Windows Chrome

## Description

The `sp-dropzone-drop` custom event does not fire on Windows Chrome (latest), silently breaking all drag-and-drop functionality for consumers of `sp-dropzone`. The same code works correctly on macOS Chrome.

## Severity

**SEV 2** — Major disruption, prevents task completion. All dropzone-based interactions (sceneline, quick actions, etc.) are non-functional on Windows.

## Root cause

The `onDragOver` handler gated `event.preventDefault()` behind a `dataTransfer` null check and the `shouldAccept` guard. The HTML5 Drag and Drop specification requires `dragover` to be canceled for the browser to allow a subsequent `drop` event. macOS Chrome is lenient about this requirement, but Windows Chrome strictly enforces it — if `dragover` is not canceled, the native `drop` event is suppressed entirely.

## Steps to reproduce

1. Open [this StackBlitz reproduction](https://stackblitz.com/edit/vitejs-vite-qrxb5dua) on **Windows Chrome** (latest)
2. Drag a file from the desktop onto the `sp-dropzone`
3. Observe that no `sp-dropzone-drop` event fires and the file is not accepted
4. Repeat the same steps on **macOS Chrome** — the drop works as expected

## Expected behavior

`sp-dropzone-drop` fires on all supported browsers when a file is dropped onto the dropzone.

## Actual behavior

On Windows Chrome, the native `drop` event is suppressed by the browser because `dragover` was not consistently canceled, so `sp-dropzone-drop` never dispatches.

## Affected components

- `sp-dropzone` and all downstream consumers relying on `sp-dropzone-drop`

## Environment

- **Browser:** Chrome (latest) on Windows 11
- **Works on:** Chrome (latest) on macOS

## Fix

Resolved in PR #6243:

- Moved `event.preventDefault()` to the top of `onDragOver` so it runs unconditionally before any guards
- Added `!this.isDragged` guard in `onDrop` to prevent `sp-dropzone-drop` from firing for rejected drags (since `preventDefault()` now always runs, the browser will fire the native `drop` even when `shouldAccept` was cancelled)
- Added `relatedTarget` guard in `onDragLeave` to suppress spurious `sp-dropzone-dragleave` events when moving between child elements
- Added `clearDebouncedDragLeave()` in `disconnectedCallback` for cleanup
- Added comprehensive test coverage for all new behaviors

## Acceptance criteria

- **Given** a user on Windows Chrome drags a file over `sp-dropzone`, **when** they drop the file, **then** `sp-dropzone-drop` fires with the file data
- **Given** a consumer cancels `sp-dropzone-should-accept`, **when** the user drops a file, **then** `sp-dropzone-drop` does **not** fire
- **Given** the user moves their cursor between child elements inside the dropzone, **when** internal `dragleave` events fire, **then** `sp-dropzone-dragleave` is suppressed and the drag visual state persists
- **Given** the dropzone is removed from the DOM during an active drag, **when** `disconnectedCallback` runs, **then** pending dragleave timeouts are cleared

Start by reviewing PR #6243 and the sp-dropzone drag handlers, especially onDragOver, onDrop, onDragLeave, and disconnectedCallback. Check the comprehensive tests added there against the acceptance criteria, including Windows Chrome drop behavior, rejected drags, child-element transitions, and cleanup.

Written by the indexing model from the issue text.