fix(artifacts): take nested container families from bytes (#1553)

Inventory gave nested members a ZIP or ASAR family from their path
suffix. Byte classification replaced it only for ZIP magic, so text named
`.apk` or `.asar` stayed a container, and encrypted entries and symlinks
kept the suffix guess. A filesystem `.asar` without an ASAR header failed
the whole inventory as a malformed archive.

Nested ZIP families now follow ZIP magic and ASAR follows its header
pickle, shared with root classification. An unread member named like a
container has an unknown format and a limitation naming the suffix. ASAR
expansion requires the header.

The Android projection adds a limitation when no root AndroidManifest.xml
was observed, and its rejection names the observed root format.

Fixes #1491

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

docs/android-analysis.md

@@ -129,6 +129,10 @@ signature validation, full resource-table semantics, native-library analysis or
 Android runtime capture. An `.aab` suffix is a ZIP archive, not an APK, so
 Android tools and the application graph do not treat it as a standalone APK.
 Existing artifact inventory/extraction tools can supply archive evidence.
+Inventory records an APK root only for ZIP bytes whose name ends in `.apk`.
+The projection adds a limitation when no root `AndroidManifest.xml` was
+observed, because such a ZIP may not be an APK. Nested members take a ZIP or
+ASAR family from their bytes; an unread member keeps an unknown format.
 Inventory keeps ZIP names that differ only in case and records that a
 case-insensitive destination cannot store both spellings. Extraction fails
 only when that destination directory cannot keep both names. Project that