fix: add missing letter ё to the Russian keyboard layout

[MiMoHo]

Type of change(s)

• Bug fix

What changed and why

The Russian keyboard layout offered no way to type the letter ё:

• With the numbers row disabled (the default), long-pressing the е key only offered 5.
• With the numbers row enabled, digits are stripped from popup characters, so long-pressing е showed no popup at all — ё was completely untypeable (matching the reporter's "nothing happens").

Fix: add ё to the popupCharacters of the е key ("5" → "5ё"), following the exact convention already used elsewhere (e.g. the Belarusian layout's є, ґ, щ). Long-pressing е now offers ё (and 5 when the numbers row is off; only ё when it is on).

I intentionally did not apply the reporter's suggested Belarusian (cyrillic) change: that layout already has a dedicated ё key (app:keyLabel="ё"), so ё is already directly typeable there and adding it to the е popup would be redundant.

Tests performed

Built the fossDebug variant and installed it on an Android 15 (API 35) emulator, with Fossify Keyboard set as the active IME and the Russian layout selected:

• Before: long-pressing е offered only 5.
• After: long-pressing е shows a 5 / Ё popup; selecting the new entry inserts ё into the text field (verified the field then contained ё).
• Confirmed the rest of the Russian layout renders unchanged.

There are no unit tests for keyboard layout resources; this is a static XML resource change verified manually on-device.

Closes the following issue(s)

• Closes Error of the Russian keyboard layout #405

Checklist

• I read the contribution guidelines.
• I manually tested my changes on device/emulator.
• I updated the "Unreleased" section in CHANGELOG.md.
• I have self-reviewed my pull request (no typos, formatting errors, etc.).
• I understand every change in this pull request.

---

_{Coded with Opus 4.8 ultracode.}

[naveensingh]

Thanks.

[naveensingh]

@MiMoHo

I see you have now submitted a large batch (22) of PRs in a short period. Please do not submit bulk AI-generated PRs or AI-generated issue comments. Even small diffs still require maintainer review, testing, and support after merging.

See https://github.com/FossifyOrg/General-Discussion#contributing-code

[MiMoHo]

Thanks for the direct feedback, @naveensingh — you're right that opening that many at once was too much, regardless of how each was prepared. I've closed the ones I hadn't individually verified on a device, and removed the analysis comments, so that's off your plate.

The handful still open are each a fix I reproduced and tested on an emulator for an already-accepted issue. Could I ask how you'd prefer I proceed — do you refuse well-tested pull requests for accepted, active issues that genuinely improve the apps' experience, or is the concern specifically the pace/volume (and unverified changes)? I'm glad to go at a slow trickle, one small tested fix at a time, or to step back entirely if you'd rather. Thanks for maintaining Fossify.

[naveensingh]

Hi, the concern is specifically the pace/volume and validation, yes. The remaining pull requests will be reviewed on a case-by-case basis.