fix(windows): preserve opaque ANSI shortcut path identity - #10547

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

Confidence Score: 5/5

[Medium impact] The reviewed changes appear safe to merge.

Summary

The PR keeps opaque ANSI shortcut bytes out of Unicode path comparisons.

• Icon and target paths stay unknown when opaque ANSI bytes cannot be compared.
• LinkInfo keeps suffix extensions when opaque ANSI text prevents a full-path comparison.

ShuaixinHuang explicitly documents opaque ANSI joins remaining unknown as intentional; this was not treated as a regression.

The security review found no actionable issue in the changed code. Review conclusions are source-based; no tests were run during this review.

Replacement status could not be independently checked because GitHub authentication was unavailable. The supplied description says this PR replaces #10181 at ShuaixinHuang’s request.

_{Reviews (1) · Last reviewed commit: "fix(windows): preserve opaque ANSI short..." · Reviewed by Greptile}

Reviewed 31cabe96 against upstream/main on Windows x64 / Node 24.22.1. I checked the direction of every behaviour change on a differential grid rather than reading the diff alone, because the risk in a change like this is a new claim, not a missing one.

The safety property holds. Across 30 target/icon pairs (ASCII, APP.EXE case variants, a trailing period, a truncated name, and an ANSI path carrying the CP932 lead byte 0x83 and trail byte 0x5C) the only changed verdicts are true → null. Nothing moved false → true or false → null, so the change never invents a difference and never invents equality — it only withdraws a claim it cannot support. That is the correct direction for an opaque-bytes reader.

Two things I confirmed rather than assumed:

• Byte-identical ANSI paths still report false. C:\工具\app.exe against itself returns differs: false, so the left.path === right.path short-circuit is doing its job and the reader does not become uselessly silent on the common case.
• target_extension is unaffected where the extension bytes are ASCII. A base path containing 0x83 still reports .exe, because the extension itself is ASCII and its bytes are unambiguous; only a non-ASCII extension goes to null. That matches what the PR body says.

Beyond the diff, the LinkInfo join behaves identically to main on a 30-cell base × suffix grid (C:\Tools\, C:\Tools, C:\Tools\app, C:\Tools\app.exe, C:\, C:\a.b\c × app.exe, "", .exe, app, x.txt) — zero divergent extension values. So the path: null branch is additive, as intended.

One observation, not a defect: recorded() computes extensionOf(path, ansi) for the icon path as well, but only targets[0].extension is ever read (observationsOf). If the icon's extension is not meant to be used, dropping that computation would keep RecordedPath's invariant narrower; if it is meant to be used, this is where it would go. Either way it is currently dead work on one path per link.

On CI: the only failing required check is Validate author declaration. That one failed for me too, on a push that changed nothing relevant, with a GraphQL 502 from openHeadsMatching (scripts/ci/pr-readiness.mjs:29) — this repo has ~890 open PRs and that query is heavy. If it stays red, re-running via an empty --amend commit clears it; it is not your diff.