dap: the editor front silently diverges from the session core — breakpoint conditions are dropped and pause never suspends

Problem

Two places where flow dap answers success for semantics it does not deliver, at HEAD 681f842:

Conditions on function breakpoints are dropped. setFunctionBreakpoints with {"name":"charge","condition":"item.sku == \"b-2\""} answers {"breakpoints":[{"verified": true}]} — and the first stop evaluates item.sku to "a-1": the breakpoint fires at every arrival. flowdap's setBreakpoints unmarshals only name. The adapter does not advertise supportsConditionalBreakpoints, so a strictly conforming client hides the condition UI — but a client that sends one anyway is told verified: true and gets different semantics than it asked for, with no message. The session core fully supports conditions (break charge if item.sku == "b-2" works at the prompt — verified in the same session), and docs/DEBUGGING.md sells exactly this ("stops at the one iteration you care about instead of all ten thousand"); from an editor the feature is unreachable, and inside a big loop the editor's buttons have no substitute.

pause claims success and never suspends. With a run parked in a 4s sleep: after continue, a pause request answers success; no stopped event ever arrives and the run continues to the end. The DAP spec for Pause: the response is followed by a stopped event (reason pause) after the thread has been suspended. The server's answer is argued as "the next stop is already coming" — true while stepping, false under continue with no matching breakpoint, which is exactly when a person reaches for pause. A client that trusts the success sits on a "running" UI until the run ends.

Evidence

Both reproduced twice via a Python DAP driver (Content-Length framing over flow dap stdio): initialize → launch → setFunctionBreakpoints → configurationDone → continue; and launch of a sleep: 4s workflow → continue → pause at ~0.5s → no stopped within 2s → terminated at 4.0s.

Desired outcome

• Conditions: either advertise supportsConditionalBreakpoints and pass the condition through the session's existing conditional-breakpoint support, or answer entries carrying one as unverified with a message saying conditions are unsupported here. Honoring them is the better half — the core already implements the semantics and the docs already promise them.
• Pause: either interrupt the session (it already supports cancellation) and emit stopped, or fail the request. A success with no following stopped is the one answer the spec does not allow.

Acceptance criteria

• A conditional function breakpoint inside a for_each stops only at the matching iteration over DAP (the prompt's existing behavior), or is answered unverified with a message.
• pause during a long sleep: either produces a stopped event or an unsuccessful response.
• The capabilities advertised in the initialize response match what the adapter actually honors.

Related: #928 (debugger umbrella; the DAP adapter is its editor-front slice), #1212 (Temporal-native pause of durable runs — a different lever; this issue is only about the local DAP session).

Start at the flow dap handlers for setFunctionBreakpoints, initialize, and pause, then trace how they connect to the session's conditional-breakpoint and cancellation support. Reproduce both cases with the Python DAP driver described in the issue and check docs/DEBUGGING.md for the promised behavior. Done means matching conditional stops and a pause response followed by stopped, or an explicit unsuccessful response, with accurate advertised capabilities.