test(review): add hard-link witness test to save-artifact overwrite guard (#12578) - #12581

Thanks for picking this up — the witness mechanism itself is right. I verified it locally against both mutants that matter: with isSameFile(outputPath, inputPath) reduced to outputPath === inputPath the new cases go red, and with an inode-blind isSameFile that always falls through to realpathSync they are the only red rows in the suite. So the discriminating power is there.

A few things need to align with #12578 and the sibling witnesses before this lands:

1. The gate is the pre-#12568 form (the one must-fix). #12568 merged today and converted isSameFile to stat(..., { bigint: true }), so a 64-bit NTFS file id above 2^53 now arrives exact and the guard is no longer inert there. Both sibling witnesses (findings.test.ts, repo-context.test.ts) moved to the narrow gate:

const inode = statSync(path).ino;
if (inode <= 0) {
  ctx.skip();
  return;
}

The !Number.isSafeInteger(inode) || inode <= 0 form here over-skips on exactly the high-id NTFS volumes this series (#11848) is about — the guard works there now, so the witness should run, not skip. It also contradicts this PR's own comment, which already describes the post-#12568 bigint behavior.

2. One case, not three. #12578 scopes this to a single case beside refuses to overwrite the %s input, and the triage thread on the issue explains why: the three labels share one isSameFile call in a single loop, so a hard-link witness on findings pins dev/ino sight for all three. Could you collapse the it.each to one it on findings and tighten the assertion to /must not overwrite the findings input/?

3. Placement and cleanup. The case belongs beside the existing overwrite it.each, not the traversal-guard block — that's where someone auditing overwrite coverage will look. The rmSync(alias) calls can go: afterEach already removes the temp root recursively, and neither sibling witness cleans up its link.

On CI: the six failures all died in Install dependencies / Build cli — infrastructure, not this change. A rebase onto current main should pick up a healthy pipeline, and is needed anyway for the gate in point 1.

LGTM — the revision addresses all three points from the previous round: a single hard-link witness on the findings input placed beside the overwrite it.each, the narrow inode <= 0 gate matching the post-#12568 sibling witnesses, and the cleanup boilerplate is gone. Full matrix green on d92c3fd (ubuntu Test, Lint & Static, no-AK Integration, TUI parity, OpenTUI no-flicker, web-shell E2E all pass). Thanks for the quick turnaround.

Approving at d92c3fdf. Independent second pass on a test-only diff.

The part worth confirming was whether the discriminating power survives collapsing three cases into one, so I checked that by reading rather than rerunning the mutants. A string-identity isSameFile lets alias !== paths.findings through, the write lands, and both the toThrow(/must not overwrite the findings input/) and the unchanged-content assertion go red. An inode-blind one that falls through to realpathSync also goes red, because realpathSync resolves symlinks but not hard links, so the two names stay distinct path strings. Both mutants from the earlier round are still killed by the single case.

Placement and gate match the sibling witnesses: the case sits directly after the it.each(['findings', 'composed', 'report']) overwrite block, which is where someone auditing overwrite coverage looks, and the inode <= 0 skip is the post-#12568 narrow form rather than the !Number.isSafeInteger(inode) one that would over-skip on exactly the high-id NTFS volumes this series is about.

18 checks pass, 8 skipped, none failing at this head; no unresolved threads.