flowdap: breakpoints are by step id and frames carry no source because `v1.Node` has no position — the compiler's `Positions` side table already maps step ids to spans for the launched file, so line breakpoints and navigable frames are a lookup away

Observed behavior

pkg/flowstate/v1/flowdap/flowdap.go:19-47 records the seam: "a node carries an id and no source position … Breakpoints are by step id, not by line … Stack frames carry no source" — and names the fix: "answerable by parsing the workflow the run is executing and mapping step ids to the positions the parser already records for diagnostics … a separate slice: it needs the file, which only a launch configuration knows". setBreakpoints is answered by refuseLineBreakpoints (flowdap/server.go:265, :655); only setFunctionBreakpoints arms anything, so in VS Code breakpoints live in the function-breakpoint list rather than as gutter dots, and a stopped frame cannot be clicked into.

The mapping exists: flowfile.Positions (flowfile/position.go:94-99) carries steps map[string]string and spans, filled by the parser for every step at every nesting depth, and Positions.Locate (position.go:180-207) already narrows a (step, field) to a span for flow validate's diagnostics. The DAP launch request receives the workflow path.

Desired outcome

On launch, the adapter parses the file once with positions, and then: setBreakpoints by line resolves each line to the innermost step whose span contains it (or refuses, naming the nearest step's line); stack frames carry source and the step's line; evaluate for hovers (SupportsEvaluateForHovers is already advertised, server.go:232-236) works over the file the editor shows. Where the parse and the run disagree (the file changed after launch), the adapter says so rather than guessing — the rule flowdap.go:38-40 sets.

Acceptance criteria

• setBreakpoints on a step's line reports verified: true with the step id; on a blank or non-step line reports verified: false with a message naming the nearest step.
• stackTrace frames carry source.path and line; the VS Code extension shows the current-position marker on the step.
• The digest of the parsed file is compared with the run's spec digest; a mismatch marks every breakpoint unverified with the reason.
• docs/DEBUGGING.md and docs/EDITORS.md describe line breakpoints; flowdap.go:19-47 is rewritten.

Constraints and dependencies

• A call: callee's steps live in another file; their frames stay source-less until #1376 / #1447 decide how a callee is addressed from a byte surface. #1439 (one step-address grammar) is what the frame name and the breakpoint id should both spell.
• Local driver only today (debugger.go:57-62); the durable attach (#928 slice 2) inherits the same mapping.

Start with pkg/flowstate/v1/flowdap/flowdap.go:19-47 and flowdap/server.go, then read flowfile/position.go:94-99 and :180-207 to understand the existing step-to-span mapping. Trace launch, setBreakpoints, stackTrace, and evaluate; done means the listed acceptance criteria pass, the digest mismatch is reported, and docs/DEBUGGING.md, docs/EDITORS.md, and flowdap.go are updated.