rules_xlsynth: split XLS runtime and toolchain bundle surfaces

[dank-openai]

Problem Solved

rules_xlsynth currently exposes one mixed repo per xls.toolchain(...) declaration. That makes the runtime surface ambiguous, forces runtime-only consumers to inherit driver/toolchain behavior, and leaves no clean way to export the full native libxls runtime closure once xlsynth starts publishing it.

This change makes the runtime and toolchain surfaces explicit. The runtime repo becomes the place that downstream consumers depend on for libxls, stdlib, artifact config, and runtime companions, while the toolchain repo layers the driver and tool registration on top.

Mental model

Each xls.toolchain(name = "...") declaration now materializes two repos:

• @<name>_runtime
• @<name>_toolchain

The runtime repo owns the closed native/runtime payload. The toolchain repo consumes that runtime surface and adds xlsynth-driver plus toolchain registration. Download-backed bundles also learn how to fetch and unpack the optional runtime-closure tarball when the selected xlsynth release provides one.

Non-goals

This PR does not publish new xlsynth release assets by itself. It only teaches the rule surface how to consume those assets when they exist.

This PR does not preserve the old mixed-surface repo shape as a long-lived compatibility contract.

Tradeoffs

The repo graph becomes more explicit: callers now choose runtime vs toolchain repos directly instead of getting both behaviors from one generated repo. That is a better end state, but it means examples, docs, self-tests, and downstream wiring all need to adopt the split naming.

Download/install resolution also becomes more capable and slightly more complex because runtime-closure assets are optional and version-dependent.

Architecture

extensions.bzl now fans one xls.toolchain(...) declaration into separate runtime and toolchain repo generators.

xls_toolchain.bzl introduces a runtime-surface provider so runtime consumers can depend on the non-driver payload directly while toolchain consumers still build a composed bundle.

materialize_xls_bundle.py splits runtime-only staging from driver-capable staging, and download_release.py learns how to fetch and unpack the runtime-closure sidecar assets.

Examples, README, DESIGN notes, self-tests, and sample BUILD files all move to the explicit @..._runtime and @..._toolchain vocabulary.

Observability

The generated repo names now make the contract visible in BUILD and MODULE files.

external_bundle_exports_test continues to act as the proof that the exported runtime surface contains runtime files but no driver.

The workspace-toolchain smoke example still builds against the split surface so downstream breakage is visible through the public examples.

Tests

Validated with python3 -m unittest artifact_resolution_test download_release_test env_helpers_test, bazel test //:external_bundle_exports_test, and bazel build //examples/workspace_toolchain_smoke:smoke_pipeline.