fix(android): cap console message length before String.format to prevent OOM (#8532)

[codebyshoaib]

Fixes #8532

Problem

BridgeWebChromeClient.onConsoleMessage runs String.format(...) on the entire JS console message unconditionally. When JS logs a very large value (a serialized IndexedDB row, an axios error/response object, etc.), the message can be tens or hundreds of MB. Materializing that into a Java String blows the WebView heap on low-RAM Android devices, producing java.lang.OutOfMemoryError and a hard crash.

In our production app this was the #2 fatal crash; one device attempted a single ~266 MB allocation on every occurrence. loggingBehavior: 'none' / 'production' does not prevent it, because the format cost is paid before logging is gated.

Fix

Cap the console message length before it is passed to String.format. Anything over MAX_CONSOLE_MESSAGE_LENGTH (8 KB) is truncated with a … [truncated] marker. This keeps the log readable while making the OOM structurally impossible, and touches nothing else.

Reproduction

In any Capacitor Android app, on a low-RAM device (or an emulator with a small WebView heap cap):

console.log('x'.repeat(100_000_000)); // ~100M chars

Before: java.lang.OutOfMemoryError. After: app stays alive; the log line is truncated.

Possible follow-up (not included, to keep this minimal)

Short-circuiting before String.format when logging is disabled would also avoid paying the cost for logs that are never emitted. I left it out to avoid assumptions about the preferred Logger / loggingBehavior API — happy to add it if the team wants it.

Notes

• The 8 KB threshold is arbitrary and easy to change — open to whatever value / config approach you prefer.
• Formatting kept consistent with the surrounding code.