fix(artifacts): defer lazy loads and tighten Mach-O validation

Address review findings in trace_dylib_resolution:
- Resolve LC_LAZY_LOAD_DYLIB dependencies without traversing them, since
  dyld loads them on first use. An unresolved one becomes
  `lazy-load-unresolved`, not a launch failure.
- Accept FAT tables up to 128 records, as target opening does. A table
  that names no Mach-O CPU type, such as a Java class file, is not
  Mach-O.
- Require 8-byte load-command alignment in 64-bit images. 1,508 real
  slices still match otool.
- Report EACCES/EPERM while probing, reading, or hashing as an
  `unavailable` failure naming the code and path, rather than generic
  io.

Findings and limitations move to dylibResolutionFindings.ts to keep the
resolver under the module size limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/apple-application-analysis.md

@@ -167,7 +167,9 @@ cache rather than on disk, so REA does not check them against the host.
 
 `findings` are derived, not observed:
 
-- `required-load-unresolved` and `weak-load-unresolved`.
+- `required-load-unresolved`, `weak-load-unresolved`, and `lazy-load-unresolved`.
+  `LC_LAZY_LOAD_DYLIB` dependencies are resolved but not traversed, because dyld
+  loads them on first use; an unresolved one is not a launch failure.
 - `earlier-rpath-candidate-absent`: a Mach-O placed at an earlier search path
   would load first. Whether code-signing library validation would reject it is
   not evaluated; use `inspect_signature`.