fix(cli): default to apksigner for APK builds

[jbbottoms]

Description

Default to apksigner when the resolved Android release type is APK. Keep jarsigner as the AAB default and preserve explicit CLI/config signing choices. Update the CLI help and configuration documentation, including the requirement that apksigner be on PATH.

Fixes #8106. Thanks to the reporters for identifying the APK installation failure and confirming the explicit apksigner workaround.

Change Type

• Fix

Rationale / Problems Fixed

buildCommand currently defaults to jarsigner for both output formats. Its JAR signing path can destroy an APK's resource alignment and does not produce the v2-or-newer signature required by modern Android targets. Selecting APK output should also select the APK signing tool unless the user overrides it.

This is separate from #8568, which rejects an explicitly incompatible AAB/apksigner combination. This PR does not change that validation or the lower-level signing functions.

Tests or Reproductions

• Eight regression cases exercise buildCommand through buildAndroid, mocking only platform selection/task logging and the external-process boundary. They cover CLI/config release types, precedence, the unchanged AAB default, and explicit signer overrides. Three APK-default cases fail on current main and all eight pass with this patch.
• macOS: npm run build --workspace @capacitor/cli passed; npm test --workspace @capacitor/cli passed (13 suites, 92 tests).
• npm run lint passed, including SwiftLint (existing warnings, zero serious violations).
• Windows: the eight new tests and TypeScript --noEmit passed.

I also built a minimal resource-only APK with Android Build Tools 36.0.0 (aapt2), min SDK 24 / target SDK 36, and aligned it with zipalign -f 4. Using the CLI's signing arguments with a disposable RSA key and JDK 21:

Signing path	zipalign -c -v 4	apksigner verify --verbose
Current jarsigner arguments	Failed: resources.arsc offset 2686, alignment remainder 2	Failed: target SDK 36 requires signature scheme v2 or newer
Existing apksigner arguments	Passed	Passed; v2 and v3 signatures verified

This was host-side signing/verification, not an Android device/emulator installation test. The test APK was generated with aapt2; I did not run a full Gradle app build.

Platforms Affected

• Android
• iOS
• Web

Notes / Comments

APK builds that relied on the old implicit JAR signer now require the Android SDK's apksigner on PATH. Explicit --signing-type jarsigner / android.buildOptions.signingType remains honored. AAB users keep the existing default.