Workflow editor signals that steps are draggable when they aren't

Bug Description

The workflow editor gives three visual cues that steps can be dragged, but dragging does
nothing and there's no feedback explaining why. On a deep workflow this costs real time:
you try to tidy the layout, nothing happens, and nothing indicates that the move
interaction is a click rather than a drag.

The cues that point the wrong way:

• Action nodes have a hover:translate-y-[-2px] lift on hover, which reads as grabbable.
• The move-mode drop target renders IconDrag, a drag-handle icon, for an interaction
  that actually requires a click.
• The canvas pans and zooms normally, so steps look like they should move too.

Meanwhile nodesDraggable={false} is set on the ReactFlow element in
HogFlowEditor.tsx, so no drag will ever do anything.

Move itself does work (shipped in #46645): select a step, choose move, then click one of
the highlighted insert points. The problem is purely that nothing communicates that, and
several things communicate the opposite.

How to reproduce

1. Open a workflow with several steps.
2. Hover a step. It lifts, suggesting it can be picked up.
3. Try to drag it. Nothing happens, with no feedback.

Additional context

This is the discoverability half of #46623, which asks for real drag handles. Splitting it
out because it's fixable without touching the layout engine or the workflow schema: change
the move-mode icon to something that reads as a target, and drop or rework the hover lift
on nodes that can't be dragged.

The harder half stays on #46623: react_flow_utils/autolayout.ts recomputes every
coordinate through ELK on each graph change and the schema has no position field, so real
dragging can't persist without a schema change.

We hit this on a production workflow seven levels deep, where the auto layout routes a
branch edge across the full width of the canvas and there's no way to tidy it.

I'd like to pick this up. The affordance change looks like a contained frontend fix and I
can have a PR up quickly. If the workflows team would rather keep it in-house that's
completely fine, and the context above stands either way.

Debug info

- [ ] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables or https://eu.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

Start in HogFlowEditor.tsx, where ReactFlow has nodesDraggable={false}, and inspect the action-node hover styling and the move-mode IconDrag drop target. Replace the misleading drag cues with visuals that match the click-to-move interaction, then verify the reproduction steps on a deep workflow and confirm that selecting Move still allows clicking highlighted insert points.