User report: dropping a desktop icon "always tends to be down to the
right" of the intended spot. Two complementary fixes.

Precision: subtract the ghost grab offset before snapping
---------------------------------------------------------
The canvas drop handler in `layer.ts` snapped to a grid cell based on
`(ev.clientX, ev.clientY)` — the cursor position. But the user grabs
a tile somewhere inside it (typically the center, ~44/48 px in from
the top-left), and the drag manager renders the ghost offset to match:

    ghost.topLeft = (cursor.x - offsetX, cursor.y - offsetY)

So the user SEES the ghost at the offset position, but the drop math
was snapping the CURSOR position. Result: every drop landed
~offset-amount down-and-right of the visible ghost. Bias exactly
equal to the grab offset — which is why the user's "down-right"
description was so consistent.

Fix: subtract `ghost.offsetX / offsetY` from the raw client coords
before the `snapToEmptyCell` call. Now the snap input is the tile's
intended top-left, matching what the user sees under the cursor.

Live preview overlay
--------------------
Even with the math fix, grid snapping skips a column when the cursor
lands right on a cell boundary. To remove that surprise, the canvas
drop target now renders a soft dashed outline at the cell the drop
WILL land in — updated on every `pointermove` while the canvas is
the active hover target, primed from the source tile's bounding rect
so it's visible from the first frame.

Implementation notes:

- One outline per layer, mounted inside the layer container so it
  lives in the same coordinate space as tiles. CSS-positioned via
  `translate3d` so updates are GPU-cheap.
- Tear-down tied to `onLeave` / `onDrop`. No leak — the listener
  detaches with the preview.
- Only fires for `desktop-file` payloads. Shortcut creates use
  row-major packing in `built-in-openers`, so a cursor-tracking
  preview would lie about the landing slot for them.
- Respects `prefers-reduced-motion` (no transition).

Files
-----
- `src/desktop-files/layer.ts` — ghost-offset math + preview install
  / teardown.
- `assets/css/desktop-files.css` — `.desktop-mode-files-drop-preview`
  styles with theming hooks (`--desktop-mode-drop-preview-bg`,
  `--desktop-mode-drop-preview-border`).

Verified: tsc, eslint, vitest 1286/1286 (existing drag tests still
pass — the snap math change is observable behaviorally but the JSDOM
ghost rect harness happens to align with the new math). Full plugin
build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User report: dragging a tile within the desktop pops a toast that
reads "admin moved this to 'another folder'" — most frequently
inside shared folders. The actor is the user themselves; nothing
external is moving the row. So the conflict is a self-409.

Root cause
----------
The fast-path repaint (`tryPatchPositions`, added 0.20.0 to fix the
"whole desktop reloads on drop" visual flash) keeps tile DOM
identity. That's the right call for the flash, but it has a side
effect: the pointerdown listener `attachTileDrag` installed only on
the wholesale-rebuild branch never re-runs, so the `placement`
captured in its closure is whatever the store held the LAST time
the layer fully repainted.

After a move, the canvas drop fires
`rest.updatePlacement( id, { … }, placement.updatedAtMs )`. That
third arg becomes the `If-Match` header. Once the server commits and
returns a fresh `updatedAtMs`, the heartbeat in shared folders
broadcasts the new value (`upsertPlacement( …, 'remote' )`). Local
store is fresh; the tile's drag closure isn't. The user's NEXT drag
of the same tile ships the old `If-Match` → server returns 409 with
`reason: 'parent_changed'` → `showConflictToast` paints "admin moved
this to 'another folder'."

Shared folders see this most because the heartbeat bumps
`updatedAtMs` on every active-peer tick, not just on mutations —
so the closure goes stale within seconds, no other-user interaction
required.

Fix
---
In `attachTileDrag`'s pointerdown handler, re-read the placement
from the live store by id before calling `dragManager.start`. The
closure-captured `placement` is now only used as a fallback when
the store no longer has the row (defensive — shouldn't happen in
practice). Every subsequent field the drag pipeline reads
(`updatedAtMs`, `parentId`, `meta.__synthFromDockItem`, file shape)
comes from the live row, so If-Match, synth detection, and cycle
detection all agree with the server's view.

Test (`tests/vitest/desktop-files-drag.test.ts`)
------------------------------------------------
- Mount layer with placement id=1, updatedAtMs=1.
- Apply a remote bump: `store.upsertPlacement({ …, updatedAtMs: 9999 }, 'remote')`.
- Verify same DOM node still in place (fast-path took the repaint).
- Spy on `dragManager.start`; fire pointerdown.
- Assert `start` was called with `data.placement.updatedAtMs === 9999`.

Suite: 1287/1287 vitest, tsc + eslint clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User report: in a column rendered as

    My WordPress | empty cell | Icon A | Icon B

dragging Icon B onto the empty cell highlighted (and dropped onto)
the My WordPress slot, not the empty one. "It only happens with My
WordPress."

Root cause
----------
The layer's repaint reserves pinned-tile slots up the column 0 axis
(rows 0 .. N-1 in pinned-order), ignoring whatever `(x, y)` the
placement actually carries in the DB. That's deliberate — pinned
icons are framework anchors, not user-positioned tiles.

But `grid.ts`'s `buildOccupiedSet` only reads stored `(x, y)`. So
the pinned tile's VISUAL cell wasn't in the occupied set. With My
WordPress pinned at (0, 0), the canvas drop's `snapToEmptyCell`
saw column 0 row 0 as free and either:

  1. Drop math: when the cursor's target cell was occupied
     (anywhere else in column 0), the column-major scan picked
     (0, 0) as the first "empty" slot — landing the dropped tile
     visually on top of My WordPress.
  2. Drop preview: the same `snapToEmptyCell` call painted the
     preview outline at (0, 0).

Fix
---
New `buildVisualOccupiedSet( placements, excludeId? )` in `layer.ts`
that mirrors the repaint's allocation: sort pinned-first, hand each
pinned tile (col 0, row pinnedIdx) regardless of stored coords,
and only fall back to `pointToCell( p.x, p.y )` for non-pinned
rows. Same iteration order as the repaint (stable sort) so the
pinned-slot indices line up exactly with what's on screen, even
when multiple pinned tiles exist (today only My WordPress, but
the flag is generic).

All four `buildOccupiedSet` callsites in `layer.ts` now route
through the visual variant:

  - Live drop-preview update (`installCanvasDropPreview`)
  - Canvas drop's `snapToEmptyCell` for desktop-file payloads
  - Canvas drop's `nextRowMajorCell` for shortcut creates
  - Folder-tile drop's `nextRowMajorCell` for shortcut creates

The plain `buildOccupiedSet` import is dropped — no remaining
callers, and the visual variant is correct for every callsite.

Test
----
New regression in `tests/vitest/desktop-files-drag.test.ts`:

  - Mount a folder with [pinned My WordPress, Icon A, Icon B] —
    My WordPress's stored coords are deliberately wild (9999, 9999)
    to prove the test exercises the bug (the layer ignores them
    and slots it at (0, 0) regardless).
  - Drag Icon B's tile from (16, 346) to (16, 126).
  - Assert the PATCH body's `(x, y)` is (16, 126), i.e. cell
    (0, 1), NOT (16, 16) = (0, 0) = My WordPress's slot.

Suite: vitest 1288/1288, tsc + eslint + build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User report: "we can't drop anything into MY WordPress app..."

Before this change, dragging a desktop tile (or any payload) onto
the My WordPress window did nothing visible. The drag manager's
hit-test walks UP from the cursor's element to the first registered
drop target, stopping at the window boundary. My WordPress never
registered a target, so the walk bailed at `.desktop-mode-window`
and the manager `cancel(session, 'no-target')`ed silently — the
ghost just snapped back with no feedback to explain why.

Fix: My WordPress now registers a CLAIMANT drop target on its
window body whose `accept` is `() => false`. The hit-test stops at
this claimant before reaching the window boundary, so the manager
paints the no-drop cursor + reject snap-back animation. Users get
visible "this surface doesn't take drops" feedback instead of
guessing whether their drop registered.

Why a no-op claimant rather than a meaningful action: My WordPress
is a read-only directory listing over the WP REST API. Dropping a
desktop tile, a placement, or a shortcut onto it has no defined
semantic — posts already exist in WordPress; the directory listing
shows them by definition. If a future story asks for "drop a tile
onto My WordPress to route to its detail dossier" (the right-click
'Navigate into' equivalent), this claimant is the natural place to
plug it in — swap `accept: () => false` for `accept: payload =>
payload.type === 'desktop-file' && payload.data.placement.file.type
=== 'post'` and add an `onDrop` that calls the existing
`wp.desktop.myWordpress.openDetail` API.

The claimant also blocks the drag from falling through to the
wallpaper canvas under the window — drop registry walks stop at
the first registered target, so a tile released over My WordPress
no longer accidentally creates a placement on the desktop below.

Implementation
--------------
In `src/my-wordpress/index.ts`'s `renderInto`, register the target
right after `activeState = state` and push the deregister into
`state.teardown` so it's cleaned up by the existing
`desktop-mode-window-closed` handler. The drag manager isn't
guaranteed to exist in headless test boot, so the registration is
gated on `getDragManager()`.

Verified: tsc, eslint, vitest 1288/1288, plugin build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User flagged: "show the label 'CANT DROP HERE' as we show in other
cases." The reject-claimant from 82692f7 already triggers the
framework's default reject chip text — proven now by an explicit
regression so a future edit can't silently regress the contract.

The test fakes the My WordPress window shape
(`.desktop-mode-window` wrapping `.desktop-mode-window__body`),
registers the same `accept: () => false` claimant the production
code wires up, starts a desktop-file drag, and asserts after the
hover:

- The hint chip is mounted on `document.body`.
- It carries `desktop-mode-drag-hint--reject` for the red styling.
- Its text is exactly "Can't drop here" (with the framework's
  curly apostrophe).

Note for testers: the chip is a runtime ghost element appended to
`document.body` — only visible AFTER `npm run build` has produced
the latest bundles. If the chip doesn't appear when dragging onto
My WordPress in a manual session, rebuild and reload before
reporting the bug.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User report: "i can still drag something over the MY WORDPRESS app
and still showing the green badge, i want the Can't drop here. Not
the drop here to move..."

I previously read this as the OPEN My WordPress WINDOW (and added a
reject claimant there in 82692f7 — which works, locked by
caff08c). But the user meant the My WordPress TILE on the
wallpaper grid. Different surface, same problem shape.

Root cause
----------
The wallpaper canvas drop target lives on `#desktop-mode-area` and
accepts every `desktop-file` / `shortcut` payload. Each tile sits
INSIDE that area. When the user drags a tile over another tile, the
manager's hit-test walks UP from the cursor's element looking for a
registered drop target, stopping at `.desktop-mode-window`. For:

  - Folder tiles: `registerFolderDropTarget` claims with
    `accept: payload-type-aware`. ✓
  - Recycle Bin: `recycle-bin-targets.ts` claims with the trash
    handler. ✓
  - **Everything else** (My WordPress, dock promotions, plugin-
    registered icons, post/page shortcuts): NO claimant. The walk
    falls through to the canvas drop target → `accept: true` →
    chip says "Drop here to move" (green).

But the drop math uses `snapToEmptyCell` on the cursor coordinates
with the visual-occupied set (now including pinned slots after
ddd4163). The occupied cell pushes the snap to the next free
cell — so the drop visually lands in a different position than
the chip implied. Green chip, divergent outcome.

Fix
---
Layer.ts now registers a per-tile reject claimant for every
non-folder, non-bin tile. New helper `shouldRejectTileDrops`
gates the registration:

  - `placement.file.type === 'folder'` → false (folder claim
    already handles it).
  - `placement.file.ref === 'desktop-mode-recycle-bin'` → false
    (the registry keys by element; a reject claimant here would
    overwrite the bin's trash target and silently break the bin).
  - Everything else → true.

The reject claimant sits in a new `tileRejectDeregisters: Map<
number, () => void >` so the wholesale-rebuild cleanup loop AND
the layer-level `dispose()` both tear it down idempotently. The
fast-path repaint preserves tile DOM identity, so a moved tile's
claimant survives without re-registration.

Registration happens in both the pinned-branch and the regular
branch of the tile-build loop, so My WordPress (pinned) AND
plugin-registered icons (non-pinned shortcuts) both pick up the
rejection.

Extension hook for plugins
--------------------------
Plugin authors who register an icon via `desktop_mode_register_icon`
and WANT to accept drops can install their own drop target on the
tile element from a `desktop-mode.files.tile-rendered` listener.
The registry overwrites by element, so their target wins over the
layer's default reject claim.

Tests
-----
Two new vitest cases in `desktop-files-drag.test.ts`:

  - "hovering a non-folder tile during a drag flips the chip to
    reject" — mounts a layer with My WordPress (pinned) + Icon B,
    walks the manager's debug target list, asserts the
    `desktop-mode-files-tile-100-reject` target is registered on
    the My WordPress tile element and that its `accept()` returns
    false for a desktop-file payload.
  - "recycle-bin tile is NOT reject-claimed — its trash target
    survives" — mirror of the above, asserting the layer does NOT
    install a reject claimant on the bin so
    `recycle-bin-targets.ts`'s trash-accepting registration wins.

Suite: vitest 1291/1291, tsc + eslint + plugin build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>