fix(apple): resolve absolute dylib paths inside the selected root

Preserve load-command paths as evidence while passing a separate root-relative lookup path to the bounded tree resolver. Apply the same containment rule to absolute install names and rpath bases, including caller-selected root symlink spellings.

Validation: 140 source tests, full check:ci, docs and runtime build passed. Compiler-built literal, rpath and relative fixtures passed CLI/stdio MCP parity, preserved both dependency edges and left all bytes unchanged. External system paths stayed outside-target; relative control was unchanged. Fixtures were not executed, and actual dyld execution was not qualified.

Closes #5637

docs/apple-application-analysis.md

@@ -228,9 +228,13 @@ root supplies. Every edge below it has `loader_conditional: true`, and a
 request that reuses it by install name is `conditional` too. Findings on those
 edges say that they apply only if the conditional image loads.
 
-Absolute install names such as `/usr/lib/libSystem.B.dylib` are
-`outside-target`. On macOS 11 and later most of them live in the dyld shared
-cache rather than on disk, so REA does not check them against the host.
+Absolute install names that name a path beneath the analyzed root are checked
+within that root, with symlinks and `..` resolved by the same bounded tree
+resolver. Absolute paths outside the root, such as
+`/usr/lib/libSystem.B.dylib`, are `outside-target`; on macOS 11 and later most
+system libraries live in the dyld shared cache rather than on disk, so REA does
+not check them against the host. Mach-O path strings are not converted from
+`file:` URLs or looked up through unrelated host paths.
 
 `findings` are derived, not observed: