Add positron.runtime.getConsoleHistory extension API

[samclark2015]

Summary

Adds a read-only positron.runtime.getConsoleHistory(sessionId, numberOfEntries?) extension API that returns recent console history for a session: the code fragments that have already run, each paired with its output and any error. It sits alongside the other session-scoped read APIs getSessionVariables and querySessionTables, and reads from the execution history service via a shared projectExecutionEntriesToConsoleHistory helper (completed executions only, oldest first, skipping the startup banner and entries without input). numberOfEntries limits the result to the most recent N and defaults to 5, applied server-side so only those entries cross the extension-host boundary rather than the whole session history.

Console history reading is gated by a new console.historyApiEnabled setting (WINDOW-scoped, default true). Users can disable it for privacy; when disabled the API rejects rather than returning content. The setting is read live so a mid-session toggle takes effect immediately.

This exists so Posit Assistant can read console history through a native tool, in line with the direction of moving assistant tools off the vscode.lm surface. The companion native tool lives in the assistant repo on branch samclark2015/expose-getconsolecontent-tool (posit-dev/assistant#1924).

Part of posit-dev/assistant#1826 (split code execution and console context into separate tools).

History of this PR

This PR originally added a core getConsoleContent tool exposed via vscode.lm. That tool has since been removed in favor of the native extension API above, so the net change to Positron core is the new positron.runtime API (plus its shared projection helper and privacy setting), not a vscode.lm tool. Recommend squashing on merge.

Release Notes

New Features

• N/A (internal extension API; the user-facing console-reading tool ships in the Posit Assistant extension).

Bug Fixes

• N/A

Validation Steps

@:assistant

Without Posit Assistant (via the positron-zed demo extension):

1. Start a Zed console session and run a few Zed commands so there is history.
2. Run the Zed: Get Console History command from the Command Palette; optionally enter an entry count (blank uses the default of 5).
3. Verify the JSON editor that opens shows the recent console entries (input/output/error/when), oldest first.
4. Disable the Console: History Api Enabled setting and re-run the command; verify the call is rejected rather than returning history.

With Posit Assistant (native getConsoleHistory tool, posit-dev/assistant#1924):

1. Open a Python or R session and run a few console commands (including one that errors).
2. Ask the assistant about a recent console result, e.g. "what did my last command print?"
3. Verify it reads the console history via positron.runtime.getConsoleHistory and answers without re-running any code.

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:assistant

Why these tags?

Tag	Source
@:critical	Always runs (required)
@:assistant	PR description

More on automatic tags from changed files.

^{readme  valid tags}

[jonvanausdeln]

2 things/questions:

1. Finding from our good friend Claude

### `getConsoleContent` with an unknown `sessionId` allocates a permanent `SessionExecutionHistory`

`$getConsoleContent` reads through `IExecutionHistoryService.getExecutionEntries(sessionId)`, which
doesn't throw for a session it hasn't seen — it *creates* one
(`executionHistory.ts:335-352`):

- constructs a `SessionExecutionHistory`
- `this._register(history)`s it onto the long-lived service
- stores it in `_executionHistories` and returns empty entries

Each of those registers an `onWillSaveState` listener that lives for the workbench lifetime
(`sessionExecutionHistory.ts:62`), and nothing ever releases it. Since `numberOfEntries` and
`sessionId` now come straight from extension input, `getConsoleContent(someRandomId)` called
repeatedly grows both memory and the save-state listener list without bound.

Two smaller consequences of the same behavior:

- A caller passing a stale or wrong session ID gets `[]` and can't tell "this session has no
  history" from "this session doesn't exist."
- It's inconsistent with the sibling APIs this one is modeled on. `getSessionVariables` /
  `querySessionTables` go through `getVariablesClient`, which throws
  `No variables provider found for session ${sessionId}` (`sessionVariableQueries.ts:21`).

Worth noting the create-on-read is arguably a latent bug in `getExecutionEntries` itself —
`clearExecutionEntries`, immediately below it, *does* throw for an unknown session ID. This PR is
just the first caller to hand it untrusted input.

**Two ways to fix, either works:**

1. Validate in `$getConsoleContent` before reading, and throw in the siblings' style so the error
   surface is consistent across the session-scoped read APIs.
2. Give `IExecutionHistoryService` a non-allocating read path (e.g. have `getExecutionEntries`
   return `[]` for unknown sessions instead of creating, or add a separate read-only accessor).
   This fixes it for any future caller too, at the cost of touching shared service behavior.

I'd lean toward (1) for this PR since it keeps the blast radius inside the new API, with (2) as a
follow-up if you want the service itself hardened.

One piece of good news: `save()` early-returns when `!_dirty`, so bogus session IDs don't write
empty history keys into workspace storage. The cost is memory and listeners, not persisted junk.

Worth a test for this too — the helper tests are solid, but nothing currently covers
`$getConsoleContent`, which is where this lives.```

2. Since things like secrets/api-keys/etc could be exposed in the console, do we want to have any gating? Or just leave that up to the extension (assistant in this case) ?

[samclark2015]

Thanks! I redid some of the session-getting logic. I also renamed the API calls to history rather than content, based on some feedback from the Assistant-side PR.

For security: I did consider this previously, and just added a default-on setting that users can disable this API with. Disabling the setting will throw an error if the API is called.

[jonvanausdeln]

LGTM!