[axechaso]

Interactive scripts still hit the MCU-oriented 255-slot frame limit: a function with 270 simultaneously live values fails before it can run on a PC. The complete FRLG 2.0 entries need 938 and 952 slots, and their unchanged BINGO functions need 362 and 282.

This separates desktop execution from portable ECX compilation, following the direction discussed in PR #86.

• Add explicit Desktop/Portable targets and include the target in successful and failed compile-cache keys. Interactive hosts use Desktop; export uses Portable.
• Execute Desktop plans through PcInterpreter with full integer operands and dynamically sized frames. Move the existing instruction semantics into a shared internal executor, preserving the public EcxInterpreter API, reference counting, cancellation and error locations.
• Reject Desktop image export and extended-frame module serialization/linking into Portable images. Desktop never uses disk cache; encodable modules retain process caching.
• Keep the MCU instruction encoding, C VM, firmware and Portable 255-slot limit unchanged. This is an in-memory instruction executor, not a new ECX format or an SSA interpreter.

Validation on Windows / .NET 10:

• Release solution build and dotnet format --verify-no-changes --no-restore.
• Upstream Windows CI: all 2,115 executed tests pass across six projects, followed by successful window-save/connection acceptance checks and Windows publishing. The import-cycle test expectation is normalized for Windows paths in a separate commit; the four affected assertions also failed on unchanged upstream.
• Upstream 32-bit and 64-bit native ABI jobs both pass. C VM/compiler required (ECSVM_REQUIRE_CC=1); the corpus now compares separately compiled Desktop execution with Portable/C VM execution.
• 12 new cases cover 256/270/1,024 live values, repeated calls, unoptimized compilation, Core host dispatch, export/cache isolation, imported-module initialization, cancellation and source locations.
• The complete FRLG entries compile without splitting BINGO. Its original library passes 324 counter checks; the isolated egg module passes 34 assertions and 1,000 state snapshots. No device run is claimed.

The macOS job was cancelled before any steps ran: GitHub reports The configuration 'macos-14-arm64-us-default' is not supported. This leaves the overall workflow cancelled despite the successful Windows/format/native jobs; no macOS build or test result is claimed.