feat: remote generations support and centralized sudo handling

[yeoldegrove]

Summary

Adds support for remote generation operations and adds centralized sudo handling.

New Features

• Added support for listing and cleaning generations on remote hosts
• Added IsRootOnExecutor() and CommandWithSudoIfNeeded() to internal/exec/exec.go
  • Automatically detects if running as root (local or remote)
  • Only adds sudo prefix when needed
  • Eliminates duplicate root checking logic across the codebase

Code Quality Improvements

• Refactored nix.CopyToTarget() to eliminate duplicated copy logic between nilla-os and nilla-home

Usage

NixOS Generations

# List generations locally
nilla os generations list

# Cleanup generations locally (keeps last 3)
nilla os generations clean --keep 3

# List generations on remote host
nilla os --target <user@target> generations list

# Cleanup generations on remote host
nilla os --target <user@target> generations clean --keep 3

Home Manager Generations

# List generations locally
nilla home generations list

# Cleanup generations locally (keeps last 3)
nilla home generations clean --keep 3

# For remote host - connect as current user
nilla home --target <target> generations list
nilla home --target <target> generations clean --keep 3

# For remote host - connect as specific user
nilla home --target <user@target> generations list
nilla home --target <user@target> generations clean --keep 3

# For remote host - connect as specific user and use specific Home Manager configuration
# (configuration must exist in "nilla home list" and hostname must match target)
nilla home --target <user@target> generations list <user@system_name>
nilla home --target <user@target> generations clean --keep 3 <user@system_name>

Implementation

Needs remote build code from #22.

NixOS Generation Retrieval

NixOS generations are stored in /nix/var/nix/profiles/system-<id>-link symlinks:

1. Current generation: Reads /nix/var/nix/profiles/system symlink to find the current generation
2. List generations: Lists all system-<id>-link entries in /nix/var/nix/profiles
3. Generation metadata: Reads nixos-version file and kernel version from kernel-modules/lib/modules directory

Home Manager Generation Retrieval

Home Manager generations can be in two locations:

• /nix/var/nix/profiles/per-user/<user>/ (system-wide)
• ~/.local/state/nix/profiles/ (user-specific)

Two layouts are supported:

1. NixOS module integration: profile -> profile-<id>-link (takes precedence)
2. Standalone Home Manager: home-manager -> home-manager-<id>-link

The retrieval process:

1. Current generation: Checks both locations and layouts, preferring NixOS module style
2. List generations: Scans directories for matching symlink patterns
3. Generation metadata: Reads hm-version for standalone, or marks as "from NixOS" for module integration

For remote operations, home directory resolution uses:

• getent passwd <user> (if available) to get home directory
• Falls back to eval echo ~<user> shell expansion

[arnarg]

I'll wait to do a full review once #22 has been completed but testing this locally, it looks like it does not elevate permissions with sudo when deleting a generation symlink on a remote target.

>> ./result/bin/nilla-os gen clean -k 1 -t <host>
> Plan
Generation  Build date             NixOS version    Kernel version
* 70        2026-01-07 16:10:41    25.11pre-git     6.18.3
  69        2025-12-01 23:50:18    25.11pre-git     6.17.9
2026/01/07 16:28:21 ERRO failed to delete generation 69: Process exited with status 1

[yeoldegrove]

Yes, I need to have a look at the permission elevation again... Will update the PR once I manged to get it running.

[yeoldegrove]

@arnarg I guess you can give it a test if it works for you now.

[arnarg]

I apologize for leaving this PR hanging for so long. It's quite big and I haven't had the time to review it properly.

I've added one comment that I'd like you to look at before continuing.

[arnarg]

I might be misunderstanding the flow but this won't behave correctly if nilla-utils is run on linux and the target is darwin (or vice versa).

This may have to run uname or the target. Or statCmd could just be ls -l --time-style=+%s <path> which afaict is portable between linux and darwin, but requires extra parsing.