feat(apple): project macOS bundle anatomy in application graphs

project_apple_application_graph accepted only IPA inventories. It now
also projects macOS .app directories and ZIP or DMG inventories that
contain applications. It reports application roots, platforms, and
every nested bundle with its path-convention role, layout, parent,
Info.plist path, executable candidates, and signing paths:
- roles: app extensions, XPC services (including inside frameworks),
  frameworks, login items, system and driver extensions, plug-ins,
  resource bundles, and helper or nested applications;
- privileged helpers in Contents/Library/LaunchServices and launchd
  plists in Contents/Library/LaunchAgents or LaunchDaemons;
- direct files of Contents/Helpers;
- symlinks by path. Their targets are not inventoried, so versioned
  frameworks are described through their real Versions/<version>/
  directories.

AppleDouble sidecars (._* and __MACOSX/) are excluded from roles. A DMG
whose contents could not be inventoried is reported as partial. Other
inventory formats remain input errors. The projection still reads no
plist or CMS semantics; it points callers at inspect_plist.

The result schema is additive. projection_id now covers the new fields,
so IPA projection IDs differ from earlier versions.

verify:macos-bundle compiles a source-owned app with clang (CLT only).
It packs it as a directory, a ditto ZIP, and an APFS DMG, and checks
identical anatomy through the CLI with stdio MCP parity. It runs in the
macOS CI job.

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

docs/apple-application-analysis.md

@@ -1,10 +1,11 @@
 # Apple Application Inventory Projection
 
 REA can project one or more authenticated `inventory_artifact` Evidence records
-for the same IPA into an Apple application inventory. The projection is
-execution-free: it reports exact paths, content hashes, detected formats,
-runtime-family hints, and path-based bridge hypotheses. It does not parse plist
-or CMS semantics or claim observed runtime calls.
+for the same IPA, macOS `.app` directory, ZIP, or DMG into an Apple application
+inventory. The projection is execution-free: it reports exact paths, content
+hashes, detected formats, bundle anatomy, runtime-family hints, and path-based
+bridge hypotheses. It does not parse plist or CMS semantics or claim observed
+runtime calls.
 
 ```sh
 rea project-apple-application-graph '{"inventory_evidence":[<inventory_artifact Evidence>]}'
@@ -29,3 +30,72 @@ Coverage is `complete-within-inventory` when the supplied pages reconstruct the
 complete authenticated inventory, and `partial` otherwise. A partial result
 states that absence is unknown. Component and bridge-candidate arrays are still
 the complete projection of the inventory that was supplied.
+
+## Application roots
+
+| Inventory root                         | Application root                                    |
+| -------------------------------------- | --------------------------------------------------- |
+| IPA                                    | Each `Payload/<Name>.app`                           |
+| `.app` directory                       | `.`, the inventoried bundle itself                  |
+| Directory, ZIP, or DMG containing apps | Each outermost `<Name>.app` followed by `Contents/` |
+
+ZIP archives made with `ditto -c -k --keepParent` report `<Name>.app`. A DMG
+reports `<image>.dmg/<Volume>/<Name>.app`; DMG child inventory needs the native
+macOS mounting adapter. When a DMG has only its root identity, the projection is
+`partial` and says that bundle absence is unknown. Other inventory formats, such
+as APK or ASAR, are rejected as input errors.
+
+`platforms` lists `macos` for deep `Contents/` application roots and `ios` for
+shallow IPA application roots.
+
+## macOS bundle anatomy
+
+`bundles` lists each application root and every nested bundle under it. Each
+bundle reports its `parent_path`, `layout`, `info_plist_path`,
+`executable_candidates`, and `signing_paths`.
+
+| Layout                | Meaning         | Content directory                             |
+| --------------------- | --------------- | --------------------------------------------- |
+| `macos-deep`          | Has `Contents/` | `Contents/`, executables in `Contents/MacOS/` |
+| `versioned-framework` | Has `Versions/` | Each real `Versions/<version>/`               |
+| `shallow`             | Neither         | The bundle directory itself                   |
+
+Roles are path conventions (`role_basis: "path-convention"`):
+
+| Role                 | Path                                                            |
+| -------------------- | --------------------------------------------------------------- |
+| `app-extension`      | `*.appex`                                                       |
+| `xpc-service`        | `*.xpc`, including XPC services inside frameworks               |
+| `framework`          | `*.framework`                                                   |
+| `system-extension`   | `*.systemextension`                                             |
+| `driver-extension`   | `*.dext`                                                        |
+| `plug-in`            | `PlugIns/*.bundle`, `*.plugin`, `*.qlgenerator`, `*.mdimporter` |
+| `resource-bundle`    | `Resources/*.bundle`, such as SwiftPM resource bundles          |
+| `bundle`             | Any other `*.bundle`                                            |
+| `login-item`         | `Contents/Library/LoginItems/*.app`                             |
+| `helper-application` | `Contents/Helpers/*.app`                                        |
+| `nested-application` | Any other nested `*.app`                                        |
+
+The components also list:
+
+- `privileged_helpers`: files directly in `Contents/Library/LaunchServices/`,
+  where SMJobBless helpers live;
+- `launchd_plists`: `.plist` files directly in `Contents/Library/LaunchAgents/`
+  (`domain: "agent"`) or `Contents/Library/LaunchDaemons/` (`domain: "daemon"`),
+  as used by SMAppService;
+- `helpers`: files directly in `Contents/Helpers/`.
+
+Symlinks are reported by path in `symlinks`. Their targets are not inventoried,
+so a versioned framework is described through its real `Versions/<version>/`
+directories rather than `Versions/Current`. When a framework has zero or several
+`Versions/*/Resources/Info.plist` files, its `info_plist_path` is `null` and a
+limitation explains why.
+
+AppleDouble sidecar files (`._*` and `__MACOSX/`) are inventory facts, but they
+describe neighbouring files. They are excluded from roots, bundle roles, and the
+anatomy components.
+
+The projection does not read plists. Use `inspect_plist` on a bundle's
+`info_plist_path` or a launchd plist to read `CFBundleExecutable`, identifiers,
+`SMPrivilegedExecutables`, `BundleProgram`, URL schemes, and usage descriptions.
+Use `inspect_signature` on an executable candidate for code-signing claims.