fix(self): self update reported success without updating (2026.8.17.2)

[Sunrisepeak]

Two things: the post-release record for 2026.8.17.1, and a fix for a defect that release verification itself uncovered.

self update reported success without updating — closes #554

Measured on a real home the day 2026.8.17.1 shipped, while updating that home so the sandbox verification could run against the release:

$ xlings self update
xim:xlings@2026.8.17.1 is already installed
[xlings] xlings -> local:0.4.51
$ echo $?; xlings --version
0
xlings 0.4.51

Isolated to the third step. use <name> latest resolves within the currently active provider:

starting state	xlings use xlings latest
2026.8.17.1 active	→ 2026.8.17.1 ✅
local:0.4.51 active	→ local:0.4.51 ❌

Same command, same workspace — both are in installed — and the result depends on which provider was active before it ran. That behaviour is defensible on its own; silently switching provider for an ambiguous name is worse. But cmd_update only checked rc != 0, and use returns 0 because it did activate something. A home that ever carried a local: build could never update again, and was never told.

cmd_update already carries a comment about exactly this shape from the 0.4.69 404. That one was fixed by checking the install step's exit code. This is the same conclusion through a different door — and it lands on the command this release kept pointing people at as a remedy.

The test is the provider, not the version

"Did the version change" is the obvious check and it is wrong: on an already-current home nothing changes and that is success, so it fails every no-op update. I know because I wrote it that way first and ran it. A namespaced active version is precisely the statement that we are not on the index build; an index install records a bare version.

update_landed_on_index_build is exported so the rule has a test. It was inline, and inline is why the original had no check at all — there was nothing to write a test against.

Verified end to end on the real home, both directions:

from local:0.4.51 active:
  [error] nothing was upgraded: xlings is still active at 'local:0.4.51'
          (the entry binary reports 0.4.51)
  [error]   `latest` resolves within the provider that is already active,
            so a `local` build keeps winning it
  rc=1

from an already-current home:  rc=0, migration nudge printed

Post-release record for 2026.8.17.1

Four artifact checks (tools/verify-release.sh) and six sandbox assertions, plus the two things that only show up by running them:

• bump-index reported SUCCESS and merged nothing. Index latest still named 2026.8.14.1 until PR #642 was merged by hand. Third time recorded, same shape each time — which is the argument for the verifier existing. Side benefit: the bot's four sha256 values and the ones computed locally from the downloads agree byte for byte, an independent check neither side could give alone.
• self update exits 0 without updating when a local: build is active #554 above, found because verifying the release required updating the home to it, and that did not work.

The notes also record the eight review angles the work was asked to cover, and say plainly which one it did not: performance was never measured.

Verification

43 unit binaries green, including four new SelfUpdateLanding cases. Version bumped to 2026.8.17.2; test_version_consistency.py passes.