fix(apktool): attribute decode refusals to the selected APK

Carry caller-selected target identity separately from launcher selection. Only fully collected ordinary nonzero decode exits represent target refusals; startup, preparation, capture and signal failures retain provider attribution. Reuse one command/preparation output projection for probe and decode errors.

Adapt the target-path correction from PR #3462 (08d3d0d3a0) and extend its producer-boundary classification and regression coverage.

Validation: 131 focused tests in 12 files, final 50 source checks, build, typecheck/lint and docs. Ten regression controls fail on baseline 4844ae812. Twenty-four tiny actual CLI/stdio MCP refusal tasks preserve every projected field except the corrected message/path. Authored launchers only; no real Apktool/JVM or native Windows claim. Heavy stress/profiling remained stopped.

Closes #3340

Co-authored-by: Peter <304086198+peter-research@users.noreply.github.com>

docs/apktool-resource-analysis.md

@@ -83,9 +83,11 @@ select Android's `values-pt-rBR`; Android qualifiers such as `pt-rBR` and
   coverage and an explicit limit, rather than reported as missing.
 - `decoded_file_count` is capped at 100,000 files; the cap is reported in
   the limitations when hit.
-- Apktool's own decode failures (`AndrolibException`, directory traversal
-  refusals) surface as `unsupported_target` with apktool's reason preserved
-  verbatim.
+- An ordinary nonzero decode exit surfaces as `unsupported_target` naming
+  the caller-selected APK, with Apktool's diagnostic and captured output.
+  Launcher startup, ownership preparation, signal termination and incomplete
+  output collection remain provider failures; they do not establish that the
+  selected APK is unsupported.
 
 ## Real verification