Fix channel drag-and-drop reliability and crosshair highlight

[SkyJoshua]

Summary

• draggable on channel/favorite rows was bound directly to a bare bool. Blazor renders that using its "boolean HTML attribute" convention, which isn't a value the browser recognizes for draggable (a true/false enumerated attribute, not a real toggle attribute) — so the row often just wasn't draggable at all. Now renders an explicit "true"/"false" string.
• Dropping a channel onto the window-split crosshair never highlighted the target arrow, unlike tab dragging. Root cause: the coordinates on the relayed @ondrag event don't track the actual cursor position for native drags, so the existing scanner never found the real hovered target. Added a native dragover listener (capture phase, since the crosshair's own handler stops propagation) that tracks the real hovered element instead.
• Channel drag-end now finalizes onto whatever crosshair target was last highlighted, matching how tab dragging resolves its drop, instead of relying on a pixel-perfect release.

You're welcome @jadennaut :P

Test plan

• Drag channels and categories within the sidebar tree, including the last item in a list
• Drag a channel onto the window-split crosshair and confirm the target arrow highlights
• Drop a channel on a crosshair arrow and confirm it opens in that split direction

[SigmaTel71]

I think I am okay with the code.
I'm still thinking why TypeScript compilation artifacts are in the repo (.razor.js and .razor.js.map files) but it is out of scope of this PR. That's something I'll ask SpikeViper later in the chat.