2026.10.17.1: an upgrade does not replace installed payloads inside a build; a dangling record does not fail every build; doctor reads, it does not change

[Sunrisepeak]

What changes

• Intent (D3). Fetcher::resolve_xpkg_path takes a PayloadIntent:
  Use (build, run, test, pack, the runtime, host tools) takes a payload the
  provider calls usable and installs or replaces only one that is not;
  Provision (mcpp toolchain install) takes the index's current packaging;
  Locate never installs. A replacement says why (Updating llvm@23.1.3 packaging revision 0 → 1 (revision 0 is below the index's floor 1)).
• Failure (D5). By the provider's error code: a deterministic refusal is
  neither retried through the command line nor followed by an index refresh,
  and its hint does not say retry; only E_NOT_FOUND refreshes, with a reason
  that is true (could not be installed; the index may predate it). A failed
  replacement of a usable payload names the revision still in use.
• Currency where a person looks (D6). mcpp index update lists installed
  payloads the refreshed index packages anew; mcpp toolchain list marks them
  (JSON installedRevision / availableRevision).
• doctor (D7). Read-only: one offline prepare_build; the toolchain it
  reports is what a build here uses (the configured default outside a package)
  with its payload's revision; a build that would install first is reported as
  that; mcpp's package home is summarized from xlings binding_state.
• Identity (D8). A toolchain payload's revision above 0 enters the driver
  identity (payload-revision: <n>).
• xlings 2026.10.17.1 (2026.10.17.1: a payload's currency apart from its integrity; a transaction is not refused by another package's dangling record openxlings/xlings#678): payload_status reports
  complete / usable / current apart; unmet() requires
  payload_currency and binding_state; scope_repaired events are shown
  (Repaired c++@16.1.0 in mcpp's package home had no registration; deactivated).
• CI (D9). ci-upgrade.yml: the previous release (read from GitHub at run
  time) builds a home; this commit's mcpp, laid out as a release, runs in it on
  Linux x86_64/aarch64, macOS and Windows; Linux adds an old-index variant
  (xim-pkgindex of 2026-10-07) and a dangling-record variant.

Why

After xlings self update && xlings update mcpp -y, a user's every
mcpp new && mcpp run failed: install of 'xim:llvm@23.1.3' failed ... sysroot update refused before metadata changed: c++@16.1.0: installed asset registration missing. 2026.10.16.1 folded "is the packaging revision the
index's" into "is the payload complete", and mcpp treated "not complete" as
"not installed" inside the build; the replacement then met a dangling record
of another package and failed on every run, while mcpp self doctor started
the same replacement and reported ok. Measured on probe PR #814: a home of
the previous release downloads gcc (101.7 MB), glibc (36.7 MB) and llvm on its
first run after the upgrade, and the reported home fails with rc 101 on every
run on x86_64 and aarch64. Design: .agents/docs/2026-10-17-upgrade-continuity-design.md.

Tests

• unit: PmPayloadIntent.* (the intent × usable × current matrix),
  PmInstallFailurePolicy.* (error code → refresh / retry).
• e2e 918: a toolchain payload re-recorded at another revision builds with no
  install call, toolchain list offers the other packaging, doctor installs
  nothing. Fails on 2026.10.16.3 (it downloads glibc, binutils, linux-headers
  and fails).
• ci-upgrade lane, run locally before push: orphan (the reported home) passes
  -- first run no download, toolchain install replaces llvm and reports the
  repaired record; snapshot passes -- index update names llvm 0 → 1 and
  glibc 2 → 4, no run downloads.

Co-authored-by: speak-agent 248744407+speak-agent@users.noreply.github.com