feat(core): extend FrameworkDetector to support split APKs

[luca-regne]

Summary

• FrameworkDetector now accepts list[Path] and aggregates file listings across all APK parts before signature matching — frameworks whose libs/assets live in split config APKs (e.g. split_config.arm64_v8a.apk) are now correctly detected without requiring a full decompile
• batuta analyze framework accepts a file or a split APK directory; when given a directory it globs *.apk and scans all parts together
• batuta apk pull now runs a lightweight framework scan (ZIP listing only, non-fatal) immediately after pulling and reports detected frameworks in both Rich and JSON output

Motivation

Split APKs distribute their content across multiple parts — native .so libraries typically land in ABI-specific splits rather than base.apk. The old single-path detector would miss these signatures entirely. This fix lets you identify the framework before committing to a full decompile.

$ batuta apk pull com.example.flutterapp
✓ Pulled to ./com.example.flutterapp/
  3 APK files: base.apk, split_config.arm64_v8a.apk, split_config.en.apk
  Framework: Flutter        ← new

$ batuta analyze framework ./com.example.flutterapp/
Scanned 3 APK parts
Frameworks Detected:
  Flutter
    - lib/arm64-v8a/libflutter.so
    - assets/flutter_assets/

Test plan

• batuta analyze framework ./single.apk — single file path still works
• batuta analyze framework ./split-dir/ — scans all .apk files in dir
• batuta analyze framework ./empty-dir/ — prints error, exits 1
• batuta apk pull <flutter-app> — prints Framework: Flutter after pull
• batuta apk pull <native-app> --json — output includes "frameworks": [...] when detected
• uv run ruff check src/batuta/ passes
• uv run mypy src/batuta/ passes

🤖 Generated with Claude Code

In general, this problem is fixed by explicitly setting a permissions block in the workflow or job to restrict the GITHUB_TOKEN to the least privileges required (typically contents: read for read‑only workflows). For this specific commit‑lint workflow, the job only needs to read commits and configuration; it does not need to write to the repo, create issues, or modify PRs. Therefore we can add a job‑level permissions block under lint-commits: specifying contents: read. This keeps existing behavior (actions/checkout and commitlint can still read the repository) while preventing any unintended write operations via the token.

Concretely, edit .github/workflows/commit-lint.yml in the lint-commits job definition. Immediately under lint-commits: (before runs-on:) add:

    permissions:
      contents: read

No imports or additional methods are needed, as this is pure workflow configuration.

In general, the fix is to add an explicit permissions block that grants only the minimal required scopes to the GITHUB_TOKEN. For the validate job, the steps only need to read the repository contents (for checkout and analysis) and do not push commits, create releases, or interact with issues/PRs, so contents: read is sufficient.

The best minimal fix, without changing functionality, is to add a permissions block under the validate job (since the publish job already has its own permissions). This block should be placed at the same indentation level as runs-on and steps. A suitable configuration is:

permissions:
  contents: read

No new imports, methods, or definitions are needed; this is purely a YAML configuration change in .github/workflows/publish.yml, specifically adding the permissions section after runs-on: ubuntu-latest (line 11) and before steps: for the validate job.