fix: delete-area hit testing at non-default zoom (#10095)

[mikeharv]

The basics

• I validated my changes

The details

Resolves

Fixes #10095

Proposed Changes

Hit-test delete areas now us client/viewport coordinates (clientX/clientY) instead of a client-to-workspace-to-client round-trip

Reason for Changes

After #10078, delete styling would still appear at non-default zoom but blocks were not reliably deleted and the trashcan lid did not animate. The coordinate round-trip misaligned hit tests with getBoundingClientRect() at certain zoom levels, but using client coordinates fixes that.

Test Coverage

• Extended dragger_test.js with generated trashcan/toolbox delete tests at zoom 0.7 and 1.5 (delete style, trashcan lid, disposal)
• Generated extra mutator workspace tests with a zoomed parent workspace (delete on pointer-over-area; no false positive on origin-only overlap). Unrelated to bug report, but felt useful enough to add.

[mikeharv]

CI on this PR is failing because main has a package.json / package-lock.json override mismatch (npm ci missing eslint@10.3.0 / prettier@3.8.3). That is unrelated to the delete-area fix.

I opened a separate chore PR to fix main for everyone: #10097

I rebased zoom-delete onto that fix so Node.js CI should pass here once the re-run completes.

[lizschwab]

Looks good once we get CI happy again

[microbit-matt-hillsdon]

I think this PR is correct and a net simplification but I was puzzled about the mechanism behind the bug as I felt the coordinates should roundtrip ok.

After poking around with Claude I think this is what went wrong:

1. Dragger.onDrag computes coordinate once and hands the same object to wouldDeleteDraggable(coordinate) and updateDragTarget(coordinate) (and onDragEnd does something similar).
2. Each getDragTarget(coordinate) calls wsToScreenCoordinates(this, coordinate).
3. wsToScreenCoordinates does workspaceCoordinates.scale(ws.scale), and Coordinate.scale() is mutating
4. So the first call scales the shared object by ws.scale in place; the second call receives an already-×scale coordinate, scales it again, and lands outside the delete area.
5. At scale = 1 it's a no-op so all's well. At any other zoom it makes a mess.

This explains why the red-cross cursor still shows (call 1, wouldDeleteDraggable, sees the correct coordinate) but things controlled by later calls go wrong (trashcan lid).

From a non-Blockly-team perspective it seems a footgun that wsToScreenCoordinates mutates its argument. This seems like it might be an easy fix. I feel the same way about Coordinate's fluent-but-mutating API but that is a much more disruptive change.

[microbit-matt-hillsdon]

@mikeharv, interested in what you think about the mutability in wsToScreenCoordinates, worth some clean-up?