apply -f chain: side patches outside project root are rejected

[lexfrei]

Problem

talm apply -f nodes/node.yaml -f /tmp/extra-patch.yaml rejects the second -f because talm runs project-root detection per file, and /tmp/extra-patch.yaml isn't inside a talm project. The chain pattern (one node file + one or more side patches) is a common Talos workflow.

Reproduction

cd $PROJECT
echo "machine: {network: {hostname: chain-test}}" > /tmp/extra-patch.yaml
talm apply --dry-run -f nodes/node0.yaml -f /tmp/extra-patch.yaml

Output:

failed to detect project root for file /tmp/extra-patch.yaml (Chart.yaml and secrets.yaml not found)
hint: run `talm init` at the project root, or move the file under an existing talm project

talosctl native upgrades this exact use case (apply multiple patches stacked); talm's per-file root detection precludes it.

Expected

The first -f (typically the node file with modeline) establishes the project root. Subsequent -f files apply as patches relative to that root without their own root-detection check — they're patches, not standalone node bodies.

pkg/commands/apply.go calls DetectAndSetRootFromFiles early, but iterates over each file independently. A reasonable change: detect root from the first file, error if it can't, then load subsequent files as plain patches relative to that root (or as absolute paths) without re-running the detection.

Why this matters

Operators use the chain pattern for:

• Apply a node body + a one-shot override (e.g. --mode=staged testing).
• Apply a node body + a debug patch (verbose kubelet logging).
• Apply a node body + a temporary cert-SAN.

Currently each side-patch needs to be moved into the project tree (or a symlink) for the apply to work. Friction with no operational reason.

Surfaced during the dev17 manual test plan exercise.