[mg-bledig]

Summary

This PR provides an alternative implementation of the Speak numbers as digits feature proposed in #439 and discussed in #418. It is not intended to be merged alongside #439.

Following Quin's suggestion to investigate Android's TtsSpan.DigitsBuilder, I explored native speech pronunciation metadata as a way to avoid modifying the speech text.

Implementation

• Uses Android's TtsSpan.DigitsBuilder to request digit-by-digit pronunciation for consecutive runs of 2–32 digits, including leading zeros.
• Preserves the original characters, lengths, and offsets, as well as existing spans and app-supplied pronunciation instructions.
• Avoids the inserted-space transformation and corresponding custom offset mapping required in Add optional Speak numbers as digits setting #439.
• Handles generated pronunciation metadata when prepared speech is sliced before TTS submission.
• Adds an optional Verbosity → Speak numbers as digits switch, disabled by default.
• Does not modify runs longer than 32 digits and does not fall back to spacing when a speech engine ignores the hint.

Testing

• Tested the native TtsSpan approach using Google Speech Services on a physical Android device, including the change from a whole-number reading of 283482 to individual-digit pronunciation when enabled.
• In a standalone experiment, Vocalizer Tessa did not reliably honour the same digits pronunciation hint.
• Added Robolectric tests on Android API 26 and 34 for digit-run limits, leading zeros, existing spans, preference persistence, speech preparation, splitting, resume, cache and the final Android TTS submission boundary.
• The previously reported build/test and lint checks passed; final CI results for this branch can provide an additional independent check.

Compatibility and trade-offs

This version depends on the chosen TTS engine interpreting Android's TYPE_DIGITS metadata. The implementation in #439 instead inserts spaces in a speech-only representation and has demonstrated compatibility with Vocalizer Tessa, at the cost of additional offset and speech-state handling.

I lean toward the native Android API approach because it leaves the original speech text unchanged and avoids custom offset mapping. However, I recognise the broader observed compatibility of #439.

These are alternatives, not cumulative changes. I'd welcome Quin's guidance on which implementation better fits BackTalk's architecture, compatibility goals and long-term maintenance.