feat(lite): hand existing installs over to agliteterm

[yeroo]

Task 4 of the product split. This is the last agwinterm-lite: old name, old AppId, old install directory, with only its updater repointed at the agliteterm feed. It branches off main, not off the rename (#192) — the build that hands over has to be the identity users already have.

Without this, every install goes quiet

The moment agwinterm stops publishing an agwinterm-lite-setup asset, the existing updater still succeeds: it fetches the release, finds no asset whose name matches, and reports nothing. No error, no notice, no route to the successor. So the handover ships before the rename, not after.

• The feed and the asset name both move. Retargeting the URL alone would have downloaded a agwinterm-lite-setup asset that happened to sit in the same release. The test seeds exactly that decoy, listed first, and asserts it is ignored.
• The prompt says what is happening — titled "agwinterm lite is now agliteterm", and explaining what the user actually needs to know: the profile comes across on first run, the old build stays installed so they can go back, and --pipe agwinterm-lite keeps working. A user who reads "0.17.4 → 0.17.5" and then finds a differently-named app in their Start menu has been surprised by their terminal.
• The relaunch starts the successor. This is the part that would have silently broken it: the apply helper takes -Exe from GetModuleFileNameW, and because agliteterm installs alongside under its own AppId, the old exe still runs after setup. A naive handover installs agliteterm and then relaunches agwinterm-lite — the user watches an update do nothing and concludes it failed. The helper now takes a -Successor, and falls back to -Exe when it isn't there: relaunching the old build is a no-op they can retry, while relaunching nothing looks like the update killed their terminal.

A bug this check surfaced, already shipping in 0.17.x

The helper relaunched a named instance with:

Start-Process $Exe -ArgumentList '--pipe', $Instance

with a comment claiming the separate array element protects a name containing a space. It does not — Start-Process joins the list with spaces and quotes nothing:

1=[--pipe] 2=[my] 3=[win]        # as its own element
1=[--pipe] 2=["my win"] 3=[]     # with the quotes in the value

So an instance named my win came back as instance my — a different pipe and a different state file. That is the "my sessions are gone" shape, caused by the update itself, on exactly the path this PR touches. The quotes are now part of the value; the app parses its own command line with CommandLineToArgvW, which strips them again.

Verification

lite/test/handover.ps1 — 21 checks — drives the built exe against a local feed through the seams the updater already has (AGWINTERM_UPDATE_API takes a path, updFetch reads local files, AGWINTERM_VERSION_OVERRIDE sets the current version), then runs the apply helper the app itself wrote to disk, with stand-in executables, so the assertion is about which one gets started rather than about Inno Setup:

PASS  the successor release is offered      PASS  the installer ran
PASS  the prompt names the rename           PASS  the successor is what gets relaunched
PASS  it says this is not a routine update  PASS  this build is NOT relaunched
PASS  it promises the profile comes across  PASS  a spaced instance name survives
PASS  it says the old build stays           PASS  a missing successor falls back to this build
PASS  it still reports the verification     PASS  and says so in the update log
PASS  the agliteterm asset was downloaded   PASS  an unreachable feed does not stop lite
PASS  the lite-setup decoy was ignored      PASS  and does not nag on startup
PASS  declining leaves lite running         PASS  an explicit check reports the failure
PASS  the apply helper was written          PASS  nothing was downloaded

Error cases are first-class here: feed unreachable must change nothing and nag nobody (asserted at startup, not just on an explicit check), and successor missing must still leave the user with a terminal.

Runs against a throwaway %LOCALAPPDATA% with a real install layout, because the update path is gated on the exe living in <LOCALAPPDATA>\Programs\agwinterm-lite — and pointing a live updater at a real profile would write payloads into it. Full lite suite green: 34 matrix cells plus log/diagnose/rotation/handover.

Two harness notes worth keeping, both of which produced passing-looking wrong results first: FindWindowExW(NULL, prev, NULL, NULL) enumerates zero windows on Windows 11, so the dialog checks all "passed" as absent until they moved to EnumWindows; and copying only *.exe into the sandbox install produced a startup error box that the dialog check happily mistook for the update prompt.

Sequencing

1. this PR merges, and 0.17.4 ships as a normal agwinterm release — the lite asset is still built and published exactly as today
2. feat(agliteterm): rename from agwinterm-lite, adopting the 0.17.x profile #192 (rename) merges, and agliteterm publishes 0.17.5 from its own repo
3. only then does agwinterm stop publishing a lite asset

Step 2 must not happen before an 0.17.4 is in users' hands, or the handover has nobody to hand over to.

The same helper text exists on #192, so the instance-quoting fix is ported there separately.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code