fix: record a rewritten root mode in the js implementation's Bom

[MarshallOfSound]

openPermissionsForSquirrelMac on the js implementation rewrites the payload root to 0775 and that lands in the cpio payload, but the Bom writer zeroes the root's mode unconditionally (which is right for parity with pkgbuild, that is what it records), so the option never made it into the Bom. The native path gets 40775 there because setPermissionOnBom rewrites the lsbom listing and mkbom writes whatever it was given.

Found this diffing the two implementations on a real app in the desktop repo: the Bom was identical for every payload path except ., which was 0 on js and 40775 on native.

Fix is to track whether transformEntry rewrote an entry's mode and only apply the pkgbuild zero to a root nothing touched. Untransformed output is byte for byte what it was, the existing parity suite still covers that.

Building the same fixture both ways with the option on, before and after:

	native	js before	js after
root mode	40775	0	40775
root gid	80	80	80
default lsbom output		differs on the . line	identical (modulo native's AppleDouble entries)

The one remaining difference in the raw records is the "architecture" field, mkbom stamps 3 on every entry where pkgbuild writes 1 for the root and 15 for everything else. That is an mkbom artifact rather than anything to do with the rewrite so the js side keeps the pkgbuild values (lsbom doesn't surface it either way).

Tests: a unit test on the writer for the rewritten root (plus one proving an ownership-only transform still leaves the root mode at 0), the existing flat spec now asserts the Bom root, and on macOS a new case builds native and js with the option on and requires identical lsbom output. All three new assertions are red on main.

[electron-npm-package-publisher]

🎉 This PR is included in version 2.6.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀