Fix Mach-O dSYM loading through symlinks ##debug

[0verflowme]

Summary

• resolve companion Mach-O dSYMs for both the opened alias and its canonical symlink target
• load dSYMs through the typed IO/bin APIs instead of command strings
• require exact parsed Mach-O plugin, architecture, machine, and UUID identity before merging debug data
• restore the main binfile and IO descriptor and clean temporary binfiles, mounts, and descriptors on every path

Root cause

Companion discovery derived both the bundle path and DWARF basename from the literal input path. A symlink with a different basename therefore searched for a nonexistent companion and lost the address-owned DWARF function interface. The old path also opened the candidate through a command string and merged it without checking UUID identity.

Validation

• clean make -j and install into a fresh private prefix
• test/db/cmd/dwarf: 21/21 passing
• sys/lint.sh libr/core/cfile.c
• manual symlink check resolves int sym._check_secret (int x);

The regressions cover alias-owned and canonical-target companions, UUID rejection, thin and universal Mach-O candidates, misleading outer slice metadata, io.autofd=false, and temporary binfile/IO/RFS cleanup.

Existing limitation

This does not change the existing deferred-loading behavior for companion dSYMs whose __debug_line exceeds the 16 MiB automatic-load limit. The prior o <dSYM>; obm- path also discarded that deferred source. Fixing it requires a separate persistent external-DWARF association and explicit idx/id replay contract.