Add an optional JADX managed-code backend

[subwire]

Supersedes #217 with the same feature branch hosted directly in binsync/declib, so the existing secret-backed IDA and Binary Ninja CI can run unchanged.

Summary

• add a native DecLib backend for APK, DEX, AAB, XAPK, JAR, class, and Smali inputs using JADX
• expose managed-code class, method, field, resource, manifest, and xref operations through the Python API and decompiler CLI
• use stable JVM/Dex reference strings so overloads and addressless managed-code objects remain unambiguous
• update the bundled agent skill and CLI documentation with Java/Android workflows, bounded-output guidance, and JADX xref cost guidance

Optional distribution model

This does not bundle the official JADX distribution or depend on an MCP server. DecLib ships only a reproducible 15 KB Java protocol bridge. At runtime it discovers Java 17+ and JADX 1.5.6+ through:

1. DECLIB_JADX_WORKER
2. DECLIB_JADX_JAR
3. JADX_HOME
4. jadx on PATH

decompiler backend status jadx --json diagnoses the installation without loading an input. Gradle is needed only by DecLib contributors rebuilding the bridge; installed wheels use the staged bridge directly.

Validation

• gradle --no-daemon -p declib/decompilers/jadx/worker test stageBridge
• verified the staged bridge is reproducible with git diff --exit-code
• pytest tests/test_jadx.py -v — 7 passed
• built and installed the wheel in a fresh virtual environment without Gradle
• tested official JADX 1.5.6 in a clean Linux container against both a real APK and a generated Java archive, including manifest/resources, source recovery, method xrefs, field xrefs, bounded binary resources, and worker shutdown

The release workflow rebuilds/tests the bridge, rejects a stale checked-in bridge, and verifies that the wheel contains it.