Improve speed and responsiveness for code entered or sent to the Console

[jmcphers]

Fixes #8915

Summary

This PR holistically addresses a number of performance and responsiveness problems around running and sending code to the console, especially in Workbench and Remote SSH scenarios.

It has the following goals:

• When you make a gesture to run code, it will always be visually acknowledged in some way within 400ms.
• When Positron is waiting on a step to prepare code for submission, it is displayed visually and can be canceled.
• There should be no redundant checks for completeness or statement boundaries.

Previously, pressing Enter in the Console triggered up to three separate is_complete_request roundtrips to the kernel (Enter handler, enqueueCode, and the pending-input queue drain), each of which is especially costly on remote configurations, and none of which gave the user any feedback or a way to cancel while it was in flight.

This PR introduces a single submission entry point (submitCode) on the Console instance that chooses the cheapest available completeness strategy:

• Input boundary provider (Flow 1) - when the language registers an InputBoundaryProvider (R does, via Ark), the input is split locally over LSP with no kernel queue. Complete statements are executed and queued individually as pre-verified fragments (so the queue drain no longer re-checks each one); an incomplete tail yields a continuation prompt; an invalid fragment executes the whole input as-is so the interpreter surfaces
  the error.
• Unprocessed mode (Flow 2) - when no provider matches (e.g. Python), code is sent with a new Unprocessed execution mode. The supervisor (running in the possibly-remote extension host) performs the is_complete_request itself before execute_request, eliminating the client-to-remote roundtrip. Incomplete code rejects with CodeIncompleteError and the Console shows the continuation prompt.
• Setting off (Flow 3) - with console.promptWhenIncomplete disabled, code runs immediately with no completeness check at all. This makes execution very snappy for people who don't want prompting.

When the code is sent to the console from the Editor via a statement range provider, we now skip the completeness check entirely (Flow 3), making this common path more responsive.

Submission is now observable state on the Console instance with debounced visuals: at 400ms the input dims slightly and a green barber pole appears; at 1000ms a "Submitting..." overlay with a Cancel button appears bottom-right.

The action bar stop button and Ctrl+C both cancel the in-flight submission (which also aborts the supervisor-side check for Flow 2). The Unprocessed mode is an internal wire detail only - accepted executions are reported as Interactive in onDidExecuteCode.

To support this, LanguageRuntimeSession.execute() is now awaitable end to end (Thenable<void> | void) so a completeness rejection can propagate back across the RPC boundary, identified by error.name
(CodeIncompleteError / ExecutionCancelledError).

Release Notes

New Features

• Console code submission is now faster, always shows visual feedback, and can be cancelled while a completeness check is in flight (Console: Reduce code execution latency by reducing roundtrips #8915).
• Multi-statement input is broken up by complete expression and executed statement-by-statement for languages that support it (Frontend should break up multiline selections that get sent to Console by complete expressions #5272).
• Added a console.promptWhenIncomplete setting to run submitted code immediately without a completeness check.

Bug Fixes

• The Console no longer waits indefinitely with no feedback when the kernel is slow or unreachable during a completeness check; a Cancel affordance is now available (Console: Poor/no feedback when kernel is unreachable #10411).

Validation Steps

@:console @:ark

R (input boundary provider path):

1. Type several statements on one line and submit: print("a") <CR> Sys.sleep(4) <CR> print("B") both execute with interleaved echo; the second appears as a dimmed queued pending-input item, then runs.
2. Type an incomplete expression and press Enter: f <- function( -> a continuation prompt appears and nothing executes. Confirm the barber pole does NOT flicker for fast checks (< 400ms).

Python (Unprocessed path):

1. Type def f(): and press Enter -> a continuation prompt appears.
2. Complete the function body and submit -> it executes.

Submission feedback / cancel (any language, simulate a slow check):

1. On a slow or hung completeness check: after ~400ms the input dims with a green barber pole; after ~1s a "Submitting... [Cancel]" overlay appears bottom-right and the stop button appears in the action bar.
2. Click Cancel, press the stop button, or press Ctrl+C -> the input becomes editable again with its text intact and nothing is executed.

Setting / regression:

1. Set console.promptWhenIncomplete to false -> incomplete input submits immediately and the interpreter reports the syntax error; no dim/barber pole appears.
2. Regression: Shift+Enter inserts a newline; history navigation works; Cmd+Enter execution from the editor works; Assistant executions work.

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:console @:ark @:interpreter @:sessions @:positron-notebooks @:packages-pane @:quarto @:connections

Why these tags?

Tag	Source
@:critical	Always runs (required)
@:console	PR description
@:ark	PR description
@:interpreter	Changed files
@:sessions	Changed files
@:positron-notebooks	Changed files
@:packages-pane	Changed files
@:quarto	Changed files
@:connections	Changed files

More on automatic tags from changed files.

Warning

This PR touches a Positron directory that isn't mapped in test-tag-paths-map.json: src/vs/editor/contrib/positronInputBoundaries/. Add an entry (an e2e tag or [] for no coverage) so future changes are tagged automatically.

^{readme  valid tags}