Be more discriminating in failure popups

[jmcphers]

This change prevents superfluous error notifications/toasts when running cells in Positron.

The issue was that we were not catching exceptions thrown by executeCode. It is appropriate for exceptions to propagate here when we can't execute the code for some structural reason, but most often the failure is caused by the code itself.

When a cell fails to execute (a runtime/syntax error, an interrupt, or the session exiting) Positron already reports it in the console. Previously the rejection from executeCode also propagated up to the command handler, which surfaced it a second time as a notification popup.

This change distinguishes the two failure modes via the execution observer's onFailed callback:

• Runtime-reported failures (the code ran and errored): logged at debug level and swallowed so they aren't shown twice. Subsequent blocks are skipped since one failed.
• Submission failures (e.g. no runtime registered for the language): logged as an error and re-thrown so the user is notified, since these aren't otherwise surfaced.

Fixes posit-dev/positron#9845

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[juliasilge]

This is working great! 🎉

Before you merge, can you please update the CHANGELOG with a note on this fix? You might need to merge from main so you get the CHANGELOG entry under the right version (we released yesterday).

[juliasilge]

This logic depends on onFailed having already fired (synchronously setting runtimeFailure) by the time we reach this catch. The ExecutionObserver docs only guarantee that one of onCompleted/onFailed is called, not their ordering relative to the executeCode promise rejecting. If that ordering ever changed or raced, a runtime error would be misclassified as a submission failure and we'd surface the popup again. Just noting the dependency for future readers; the failure mode is only a graceful regression to the old behavior, so nothing to change here IMO.

[jmcphers]

Yes, it's a little kludgy! I think a more complete fix might be to throw specific structured error classes from Positron to distinguish "can't run code at all" errors from "code ran but it failed" errors.