Implement conditional breakpoints

[lionel-]

Adds support for conditional breakpoints in the DAP server. When a breakpoint has a condition expression, it is evaluated at hit time in the breakpoint's local environment. The breakpoint only stops execution if the condition is truthy.

The condition is stored as a string in the Rust Breakpoint struct and evaluated on the R thread via a new ps_should_break registered function that combines the enabled check with condition evaluation. The DAP mutex is dropped before calling back into R to avoid deadlock.

Condition results are coerced via as.logical() so R's standard truthy/falsy rules apply: 0 skips, 1 stops, nrow(df) works naturally. If evaluation errors or the result can't be coerced to scalar logical (e.g. an environment), the breakpoint fires to avoid silently swallowing typos in conditions. From a quick search this seems standard among DAPs (e.g. js/ts, python). If we feel strongly that we should be stricter, we can revert the last commit.

Conditions that fail with an error always trigger the breakpoint to avoid silently skipping them. The error is logged in the console.The message is fenced with a breakpoint header that includes a link to the breakpoint location:

If there is any output, warning, or messages, we log in the console too.

QA Notes

Comprehensively tested on the backend side (10 integration tests covering true/false conditions, loop iteration, local variables, error conditions, numeric coercion, mixed breakpoints, and live condition updates).

To test manually:

foo <- function(x) {
  y <- x * 2
  y + 1
}
for (i in 1:5) {
  foo(i)
}

1. Set a conditional breakpoint on y <- x * 2 with condition x == 3. Run the loop, should stop only when x is 3.
2. Edit the condition to x > 4 without re-sourcing. Run the loop again, should now stop at x == 5.
3. Try a numeric condition like x - 2 (should skip when x == 2 since 0 is falsy).
4. Try a broken condition like nonexistent — should stop on every hit rather than silently skipping. You should see the error in the Console with a link to jump to the breakpoint.
5. Output, warnings, and messages emitted by the breakpoint conditions are logged in the Console.

[DavisVaughan]

Tried it out on case_when() and it seems to work pretty nicely!

[DavisVaughan]

Suggested change

	pub(crate) fn with_capture<T>(f: impl FnOnce() -> T) -> (T, String) {
	let mut capture = Console::get_mut().start_capture();
	let result = f();
	let output = capture.take();
	drop(capture);
	(result, output)
	}
	pub(crate) fn with_capture<T>(f: impl FnOnce() -> T) -> (T, String) {
	let mut capture = Console::get_mut().start_capture();
	let result = f();
	let output = capture.take();
	(result, output)
	}

That seems a bit superfluous?

[DavisVaughan]

can we move tests to the very bottom? i totally skipped over eval_condition() because i thought this was the end of the file

[DavisVaughan]

feels like the right semantics to me

[DavisVaughan]

I had wondered what this mysterious 3rd diagnostic field was when reading the rest of the code.

...it's just what we get when a conversion from an R bool to Rust bool fails?

That feels like maybe a bit of overkill? Can we just tie that in with conditions or something instead?

I think it would have cleared things up for me quite a bit while reading the rest of the code.

[DavisVaughan]

Also I agree that stopping on errors feels good! And I like the console output idea