Fix attachment overlay leaking into pane resizes

[gaelcado]

Summary

• remove the cached conversation attachment-drag flag
• derive the drop overlay directly from GPUI typed drag payloads
• prevent pane resize and other unrelated drag markers from revealing the attachment overlay
• preserve external path, workspace path, and file-backed tab drop behavior

Root cause

FileDrop::Exited clears GPUI's active external payload without emitting a final mouse-move event. The shell's cached file_drag_active flag could therefore remain set. A later internal drag, such as grabbing a resize seam, satisfied the generic active-drag guard and made the stale attachment overlay visible again.

Verification

• rustfmt --edition 2024 --check crates/ui/src/shell.rs
• git diff --check
• cargo test -p zeron-ui --lib shell::tests:: -- --nocapture (48 passed)

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[wingleeio]

Reviewed the overlay change and pinned GPUI drag-style, hit-testing, and drop-dispatch behavior. No blocking findings. Typed payload matching removes the stale state while preserving the existing attachment handlers and allowing underlying mouse interaction. Formatting and diff checks pass; the full UI suite, Linux browser, iOS, and session-sync CI checks pass. Waiting for the remaining macOS check before merge.

[gaelcado]

Follow-up CI investigation after merge:

• This PR's Linux run passed on synthetic merge commit a7402d13, while the subsequent main run failed on 27046153.
• Both commits, and PR head 391ee86e, have exactly the same complete tracked-source tree: ef03f60b2922745c25d1eaae7dd64ef0e14db752. There was no source-tree change between those passing and failing cases.
• Main failed with fixture window not visible at the screenshot helper's single xdotool search --onlyvisible --pid lookup. The helper does not wait/retry for window visibility, making startup/readiness timing a plausible explanation—not a proven root cause.
• DRI3 warnings also occur in passing logs, so those warnings alone do not explain this failure.

This establishes nondeterministic behavior under the same tracked source tree, rather than a new source change introduced by the merge. It does not distinguish fixture/environment instability from an intermittent application/platform bug. The overlay change runs in the real-shell fixture, so absolute causal exclusion would be too strong.

Is this window-startup/capture failure a known issue? A same-commit rerun plus a focused readiness investigation seems useful. No CI reruns or code changes were made during this review. This is also distinct from #341's menu-input-restoration assertion; a shared cause has not been established.