Matching kubectl's own merge semantics, not inventing new ones

kubectl already has a standard way to combine multiple kubeconfig files — pointing the `KUBECONFIG` environment variable at a colon-separated list of paths and running `kubectl config view --flatten` — and this tool deliberately reproduces that exact "merge by name, last file wins on conflict" behavior rather than some different merge strategy. That matters because the whole point of a merge tool is predictability: if this tool merged differently than kubectl itself does, the merged file it produces could behave differently than expected the moment it's actually loaded by kubectl, which would defeat the purpose.

Why order-independent equality matters for conflict detection

The same cluster or user entry, re-saved through different tools or kubectl versions, can end up with its keys in a different order in the YAML even though the actual configuration is identical — a purely textual comparison would flag that as a conflict when nothing meaningful actually differs. This tool compares entries structurally instead, walking the parsed object rather than the raw text, so two entries are only flagged as a real conflict when their actual content differs, not when formatting or key order happens to differ between the two source files.