Expose last build outcome via BuildStateService

[jainapurva]

Motivation

There is no in-process way today for an Arduino IDE contribution to read the result of the last compile / upload without re-running the build. This is a recurring pain point for anything that wants to react to build outcomes — "rerun the last failed build" UI, build-history widgets, CI integration helpers, third-party assistants, etc.

What this PR adds

A small, read-only BuildStateService (under arduino-ide-extension/src/common/protocol/ and node/) that captures the result of the most recent compile or upload:

interface BuildState {
  readonly output: string;
  readonly errors: string;
  readonly timestamp: string;
  readonly success: boolean;
}

interface BuildStateService {
  getLastBuild(): Promise<BuildState | undefined>;
  setLastBuild(state: BuildState): Promise<void>; // internal, called by CoreServiceImpl
}

CoreServiceImpl writes to it from the existing compile and upload flows. The recording call is wrapped so that failures are swallowed — BuildStateService is observational and can never break a real build.

Exposed as a JSON-RPC service at /services/build-state following the same bind/ConnectionHandler/JsonRpcConnectionHandler pattern as the other shared backend services.

Why now

We're building a third-party AI assistant plugin on top of Arduino IDE 2.x and ran into this gap. Rather than fork, we'd like the service upstream so anyone (including future first-party features like a build-history view) can consume it.

The PR is intentionally scoped to just the service:

• no UI changes
• no behavioral changes
• no public API beyond getLastBuild()
• existing types & file layout untouched

Testing

• npx tsc --noEmit passes against arduino-ide-extension
• Builds via standard yarn build
• Verified the service receives both success and failure cases by triggering compile + a deliberate compile error in a local IDE build

Scope

Strictly one enhancement, per the PR guidelines. Happy to split further if reviewers prefer (e.g. service interface in one commit, CoreServiceImpl hook in another), but it's currently a single atomic commit.

Related

Part of an RFC we've drafted around small extension points that would let AI assistant plugins exist without forking. Posting that as a Discussion separately; this PR stands on its own merits.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}