Stop building the temporary filename out of the whole path (#716)

[MongLong0214]

Partially addresses #716; the observation that produced it is on #714.

An owner ran v1.0.2 on a real Windows machine with agents present — the run #714 was holding open. Every detected host failed and no config was written. gemini-cli printed the cause:

open 'C:\Users\u\.gemini\.C:\Users\u\.gemini\settings.json.commitlore-41756-….tmp'
      └── dirname ──────┘  └── the whole path, used as a filename ────┘

Both atomic writers built the temporary name with path.split('/').pop(), which returns its argument unchanged when there is no / in it — true of every Windows absolute path. A drive letter cannot be part of a filename, so the write was ENOENT before it started.

Why not basename

basename is correct here on Windows. It is also unfalsifiable anywhere else, and this repository has no Windows evidence to lean on: CI has no coding agent, so the install-ps1 job detects nothing and never reaches this line — the whole of #714. Splitting on either separator makes the property one a POSIX runner can fail on, which is the only kind of guard that can hold a Windows-only defect here.

Not fixed here

The second cause in #716: hasCommand stats each PATH entry with the bare command name, so it never finds cursor.cmd or claude.cmd, and spawnSync(..., { shell: false }) cannot execute a .cmd shim. That accounts for codex mcp add failed, Hermes setup failed, and claude-code reported notDetected with its config present. Fixing it needs a design that preserves the reason shell: false was chosen — the wrapper path and config paths reach those calls — so it is not folded in here.

Verification

Restoring split('/') fails 2 of the 4 new cases, including the Windows path producing .C:\Users\u\.gemini\settings.json.commitlore-pid-uuid.tmp where .settings.json.commitlore-pid-uuid.tmp is required. 7 cases pass across the two installer-hosts suites; tsc --noEmit clean; build:canonical then artifact:verify → 8613363cdee2183e7a6f693b31450d715f3f316ba32a4ed77272b8af9d9c9c0f.

No Windows machine has run this fix. The guard proves the name, not the install. #716 stays open for the second cause and for a Windows readback.

[github-actions]

CommitLore — record lint

Trailers: clean — 2 commits in origin/main..bd297e12bf599e7fe9038be7abb5d1ca3b695afa
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 7 paths; query one path at a time to follow its rename chain (7 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}

[MongLong0214]

Post-merge note on the artifact digest.

This branch's record (r-wintmp716) verifies artifact:verify -> 8613363cdee2183e7a6f693b31450d715f3f316ba32a4ed77272b8af9d9c9c0f. That is true of the commit it sits on. After #715 landed, main moved and this branch merged it; the two committed build artifacts conflicted, which is expected — three open PRs each regenerate dist/commitlore.mjs and installer/canonical-artifact.json.

Resolved by regenerating rather than by picking a side. A generated file has no correct side; the only answer is to rebuild it from the merged source:

build:canonical then artifact:verify -> d20d47b227b226b1b352fc5c6f9527d9b1653115d54536196948b79fdbfe3a6f

So a reader checking the record against the merged tree finds two different digests, and both are right about different commits. Recorded here so that difference is not read as a build that drifted.

No force push was used — the update is a merge of origin/main into this branch.