Open attached executables through procfs

[jeet-dekivadia]

Summary

• keep /proc/<pid>/exe intact while loading an attached process executable
• use the procfs symlink target only when matching the executable name reported by /proc/<pid>/maps
• preserve the existing realpath behavior for ordinary executable paths

Fixes #307.

Why both paths are needed

For a process in another mount namespace, /proc/<pid>/exe remains openable from the host even when its symlink target, such as /app/server, is not present in the host filesystem. Concretely, readlink("/proc/123/exe") can return /app/server while open("/app/server") fails on the host and open("/proc/123/exe") succeeds. The maps file still reports /app/server, so stop-filter address calculation needs the readlink result for its pathname comparison while ELF loading needs the procfs path itself.

Validation

• git diff --check
• reviewed both executable consumers: ELF loading now receives the procfs path for attach mode, and map-name comparison resolves only procfs executable symlinks with readlink

[jeet-dekivadia]

I rechecked this today while it is waiting for review. The patch stays on the attach path: when magic-trace is reading symbols for an already-running target, it opens the executable through procfs so the path is resolved in the target process context instead of the tracer's current mount namespace.

The startup/non-attach path still uses the existing executable resolution. DCO is green, and the PR has no red checks.