feat(xgoruntime): implement SPX runtime-provider source mode

[joeykchen]

Summary

This PR implements the SPX side of XGo runtime provider v1 described in #1741.

It intentionally completes source mode only. Published SPX module/bridge mode remains fail-closed until immutable bridge manifests and the coordinated release pipeline are available.

What changed

• Raise gox.mod to the XGo 1.8.0 capability baseline and declare runtime v1 github.com/goplus/spx/v3/cmd/xgoruntime.
• Add the SPX provider command and protocol adapter, with declaration, provider-package, effective-module, and built-artifact provenance checks.
• Support SPX as the main module, a workspace module, or an unversioned local replacement.
• Build a fresh interpreter bridge from the SPX source selected by the effective graph with host CGO_ENABLED=1; compilation may reuse the Go build cache.
• Reject regular versioned dependencies, pseudo-versions, and versioned replacements explicitly until published bridge manifests exist.
• Align command, export, native interpreter, engine-path, pack, and test-resource handling around explicit project and asset roots.

Runtime and build behavior

• Run with independent read-only ProjectDir and AssetDir roots plus a disposable SessionDir, without writing runtime state into the project.
• Acquire Engine/PCK from either a verified local runtime manifest or a code-pinned published release manifest.
• Exclude $GOPATH/bin from runtime discovery; file names and existence alone never establish runtime identity.
• Build an allowlisted project bundle and embed Engine, PCK, bridge, manifests, and project payload into a self-contained launcher.
• Reject symlinks, special files, path escapes, duplicate/case/Unicode collisions, oversized inputs, malformed archives, and identity changes while reading.
• Write only the private staging output supplied by XGo; Darwin launchers are ad-hoc signed after linking and are not modified afterward.
• Preserve Engine exit status and supervise cancellation, signals, and child-process cleanup.

Cache and offline reuse

Engine, bridge, and project components are materialized in separate content-addressed namespaces. Every cache hit is revalidated against manifest metadata, file type, size, and SHA-256. Damaged entries are repaired under an exclusive lease, and atomic publication prevents concurrent processes from observing partial state.

A built launcher contains its complete payload, so its first run with an empty cache requires neither the Go/XGo/SPX toolchain nor a network connection. Published Engine/PCK acquisition is supported independently of published SPX bridge mode.

Verification

Added coverage for runtime-manifest pinning and acquisition, offline/cache-hit behavior, same-size tampering, concurrent materialization and repair, strict payload/archive parsing, project allowlists, filesystem roots, process supervision, provider request validation, source provenance, and launcher execution.

The full Go test suite passes in a temporary workspace containing the matching companion goplus/mod checkout. Focused runtime, payload, project, release, launcher, command, pack, and engine suites also pass independently where they do not require the unreleased protocol module.

Dependencies and follow-ups

• Depends on goplus/mod#164 for runtime metadata, resolved provenance, and the v1 protocol.
• Depends on goplus/xgo#2847 for discovery, provider execution, process semantics, and transactional build/install publication.
• Before merge/release, SPX must consume the released companion module versions.
• Published mode still requires immutable bridge manifests bound to the SPX source and Engine interface digest, plus coordinated release artifacts and real-host release smoke tests.

Part of #1741. This PR must not close the proposal while published mode and coordinated release remain pending.