Fix macOS build hangs and test compilation errors

[codebestia]

Problem 1: Build hangs at 256/258 CMake targets on macOS

Issue

When running just monero_sys on macOS, the build would consistently hang at CMake build progress [256/258], preventing the build from completing. This occurred during the final linking phase of large static libraries (wallet_api and wallet).

Root Cause

The build was using full CPU parallelism (num_cpus::get() = 8 jobs on typical Macs) for CMake builds. During the final linking stage, multiple large static libraries were being linked in parallel, causing:

1. Linker deadlocks: The macOS linker (ld) can deadlock when multiple large static library links compete for the same dependency libraries or file system resources
2. Resource exhaustion: Parallel linking of large libraries (wallet_api, wallet, randomx, epee, etc.) exhausted memory/swap or I/O bandwidth
3. Dependency contention: Targets 256-258 (the final wallet_api and wallet libraries) were waiting for shared dependencies to finish linking

Solution

• Reduced build parallelism on macOS: Changed from using all CPU cores to 2 parallel jobs (-j2) on macOS
• Limited link parallelism: Set MONERO_PARALLEL_LINK_JOBS=1 on macOS to ensure only one linking job runs at a time

Changes:

• monero-sys/build.rs: Added macOS-specific logic to reduce -j from num_cpus::get() to 2
• monero-sys/build.rs: Added MONERO_PARALLEL_LINK_JOBS=1 CMake define for macOS targets

Trade-off: Builds will be slower on macOS (2 jobs instead of 8), but they will complete successfully without hanging. Other platforms continue to use full parallelism.

---

Problem 2: Test compilation failures due to Scalar type mismatches

Issue

Running cargo nextest run failed with compilation errors in test code:

1. swap-machine/src/lib.rs:98: Scalar::one() doesn't exist in curve25519-dalek v4.1.3
2. swap-core/src/monero/primitives.rs:728,736: Type mismatch between curve25519_dalek::Scalar and curve25519_dalek_ng::scalar::Scalar when calling monero::PrivateKey::from_scalar()
3. swap-machine/src/lib.rs:96: Type mismatch - xmr_locked() expects TransferProofMaybeWithTxKey but was receiving TransferProof

Root Cause

The codebase uses two different curve25519-dalek crates:

• curve25519-dalek (v4.1.3) - used in swap-core and swap-machine
• curve25519-dalek-ng (v4.1.1) - used internally by the monero crate

These are distinct types that cannot be directly converted. Additionally:

• Scalar::one() was removed in newer versions of curve25519-dalek
• monero::PrivateKey::from_scalar() expects curve25519_dalek_ng::scalar::Scalar, not curve25519_dalek::Scalar
• The API changed to require TransferProofMaybeWithTxKey instead of TransferProof

Solution

• swap-machine/src/lib.rs: Replaced Scalar::one() usage with constructing a dummy private key from fixed bytes using PrivateKey::from_slice(), and added .into() to convert TransferProof to TransferProofMaybeWithTxKey
• swap-core/src/monero/primitives.rs: Changed from monero::PrivateKey::from_scalar(Scalar::random(...)) to monero::PrivateKey::from_slice(scalar.as_bytes()), following the existing pattern in PrivateViewKey::new_random()

Changes:

• swap-machine/src/lib.rs: Construct dummy private key from bytes instead of using Scalar::one(), and convert TransferProof to TransferProofMaybeWithTxKey using .into()
• swap-core/src/monero/primitives.rs: Use from_slice() with scalar bytes instead of from_scalar() to avoid type mismatch

This approach avoids mixing the two Scalar types by working with raw bytes, which both crates can handle.