fix(software-install): relax nlink on target rollback restore

[rldyourmnd]

Problem

software-install failed with:

target identity changed

even on a freshly-managed target created by the manager's own install.

Root cause

install_or_update_software creates the target's software/ and bin/ subdirectories (lines 5018, 5020) between capturing the target identity snapshot (line 4945) and the rollback restore. On any failure after those mkdir calls, the else-branch rollback (line 5182) invoked restore_directory_metadata with the default require_nlink=True. The now-higher nlink (two new subdirectories) failed the comparison.

This reproduced on a freshly-managed target because software-install against an existing target takes the else branch (created_target is False) after legitimately raising target.nlink.

Fix

Pass require_nlink=False at the call site (line 5182). dev/ino/uid/gid still guard the real anti-TOCTOU identity; only nlink is relaxed. This mirrors the five other pi call sites that already pass require_nlink=False where subdirectories are expected to be created/removed mid-operation (lines 1038, 1369, 1474, 1571, 2692, 2790), and matches what every sibling harness (cline, qwen, codex) does by omitting nlink from the comparison entirely.

This fixes the production `software-install` rollback path. A separate, pre-existing umask-sensitivity issue affects the private fast-lane test fixtures (27 failures on clean `main` under umask 0002, green under the pinned umask 022 gate) and a subsequent cleanup path-length issue surfaces further down software-install; both will be addressed separately. This PR does not change test outcomes relative to the pre-existing baseline.