fix(pm): normalize extracted file permissions to 0o644/0o755

[elrrrrrrr]

Summary

• Tar entries from some npm packages ship with restrictive modes (e.g. google-protobuf@4.0.2's package.json, google-protobuf.js, README.md, and LICENSE* are all 0o640). Preserving the raw tar mode leaves those files unreadable by "other", which breaks container runtimes and multi-user setups.
• Normalize extraction to match npm/pnpm: 0o755 if any exec bit is set in the header, 0o644 otherwise. The existing skip-chmod-for-0o644 fast path still applies to typical files.
• Added a regression case to e2e/utoo-pm.sh that installs google-protobuf@4.0.2 into a temp dir (cold cache forced) and asserts every file is world-readable and package.json is exactly 0o644.

Repro (before)

$ tar -tvf google-protobuf-4.0.2.tgz | grep '^-rw-r-----'
-rw-r-----  package/google-protobuf.js
-rw-r-----  package/package.json
-rw-r-----  package/README.md
-rw-r-----  package/LICENSE.md
-rw-r-----  package/LICENSE-asserts.md

$ utoo install  # files land on disk at 0o640 (unreadable by "other")

After this change they land at 0o644, matching npm install / pnpm install.

Test plan

• cargo test -p utoo-pm
• ./e2e/utoo-pm.sh — new "tarball permission normalization" case passes
• Manually confirmed: node_modules/google-protobuf/*.js,*.md,package.json all 0o644 after cold install

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces tarball permission normalization during the extraction process to ensure that files are world-readable, aligning with npm and pnpm conventions. Files with any executable bit set are now normalized to 0o755, while all others are set to 0o644. Additionally, an end-to-end test case was added to verify this behavior using the google-protobuf package and to prevent future regressions. I have no feedback to provide.