Fix auto-capitalization when editor context is unavailable

[AsafMah]

Problem

RichInputConnection.getCursorCapsMode currently turns an unavailable surrounding-text read into an empty string: directly for web editors, or via the cleared cache after a failed native-editor reload. CapsModeUtils then interprets that empty string as an affirmative sentence start.

A synthetic editor containing hello there, with its cursor at 11, reproduces the defect when getTextBeforeCursor returns null (or an empty result despite a known nonzero cursor). The editor itself reports no caps. The current implementation returns CAP_MODE_SENTENCES instead, including through InputLogic.getCurrentAutoCapsState when auto-caps adds a sentence request to an ordinary text field.

Change

• Preserve the distinction between an unavailable read and an actual empty field/start position. Null context, or empty context without a known zero cursor, uses InputConnection.getCursorCapsMode with only the requested caps bits; its result is masked to those bits.
• Preserve explicit character capitalization and the known word boundary supplied by a phantom space. A zero editor response does not invent a sentence boundary. Context-independent requests do not need an extra caps RPC.
• Keep composing-text early returns and language-aware CapsModeUtils handling for available context unchanged, including real field starts and German punctuation rules. Healthy native cached-text queries perform no additional IPC.

The fallback adds a caps RPC only when context is unavailable and context-dependent modes are requested. Without surrounding text, a pending phantom space alone cannot establish that preceding punctuation ended a sentence; the fallback deliberately does not guess.

Verification

Test-first: the 24 focused tests produced 16 assertion failures before the production change, including both actual InputLogic integration cases returning 16384 instead of 0. The same 24 tests pass after the change.

The dedicated fixture uses a real editable BaseInputConnection: text and cursor remain present while only the surrounding-text response is made unavailable. Coverage includes native/web null and empty responses, unknown/stale cursor positions, reload recovery, requested-mode masking, character/word/sentence caps, phantom spaces, composing text, local language rules, and healthy-cache IPC counts.

Nearby verification with JDK 21 and Android SDK:

.\gradlew.bat :app:testStandardDebugUnitTest --tests '*RichInputConnectionCapsModeTest' --tests '*InputLogicTest' --tests '*WordComposerTest' --tests '*SuggestTest' --tests '*ContenteditableDuplicationFixTest' --console=plain

Fresh XML results: 148 passed, 1 existing ignored Hangul test, 0 failures/errors across 149 tests. The offline debug variant was blocked before tests by the existing flavor minSdk 21 / graphics-path:1.1.0 minSdk 23 manifest mismatch; no dependency or build configuration was changed.

Scope

This fixes the demonstrated missing-context fallback defect, not every report of capitalized suggestions. The exact WhatsApp/Discord user scenario has not been reproduced on a device; no device validation or APK build is claimed. Dictionary casing, acronyms/proper nouns, suggestion/contraction ranking, manual Shift/Caps Lock, other cursor bookkeeping, and nonempty truncated-context heuristics are unchanged.

One independent code-and-tests commit, based on upstream b718d832c41ba01e1cce613f14e6209c279e9d17.