Always show emoji category tabs, decouple them from toolbar hiding

[MiMoHo]

Draft for discussion – this reverses part of the design from #1606, so I'd like your opinion before polishing it.

Motivation

With the toolbar hidden and "Hide clipboard and emoji toolbars too" enabled (which is the default, PREF_TOOLBAR_HIDING_GLOBAL = true), the emoji palette loses its category tab strip. Categories can then only be reached by swiping through every page, which users don't discover – see #2546 ("Can't find all list of emojis", diagnosed in-thread as exactly this setting).

The underlying issue: the emoji category tab strip is navigation, not a toolbar. It's the only way to jump between emoji categories, so hiding it as if it were a row of toolbar tools removes core functionality rather than just decluttering.

Change

• Emoji category tabs are now always shown in the emoji view, as an anchor/extension on top of the keyboard, independent of the toolbar setting.
• The clipboard toolbar now simply follows the main toolbar setting: toolbar hidden → clipboard toolbar hidden. (Users who want clipboard toolbar keys can enable the toolbar.)
• Because the strips now either match the main view (clipboard) or are always shown (emoji tabs), the separate toolbar_hiding_global setting no longer has a distinct meaning and is removed (with a small migration in AppUpgrade to drop the stored pref). The secondary-keyboard height adjustment tied to it is no longer needed either.

This follows a "works best for most" approach: one less setting, and the emoji navigation is never accidentally hidden.

Open questions

• Are you OK with dropping toolbar_hiding_global? The alternative is to keep the setting but make it only affect the clipboard toolbar (never the emoji category tabs). I went with removal for simplicity, but can switch to the narrower change if you'd prefer to keep the option.
• Height: since emoji/clipboard no longer subtract the strip height when the toolbar is hidden, both views keep the main keyboard height. I tested this on an emulator (Android 15) and the emoji view looks consistent, but a second look on real devices/floating mode is welcome.

Testing

Built and tested on an emulator with the toolbar hidden:

• Emoji view now shows the category tab strip and category switching works (previously the strip was gone and only swiping changed category).
• No crashes switching between alpha / emoji views.

assembleDebug and testRunTestsUnitTest pass.

Refs #2546, #374, #1606.

[eranl]

The reason for adding toolbar_hiding_global was that when the toolbar is hidden, the keyboard becomes shorter, and if the emoji or clipboard bars remain shown, the net viewing area becomes shorter.
We wanted to avoid changing keyboard height when switching modes, since that seemed visually unpleasant.
So we wanted to allow users to choose how to use the shorter space - less viewing area or no bars.
It had nothing to do with what the bar is used for. See discussion at the top of #1606.
BTW, one of the reasons for adding emoji navigation by swiping was in order to support this mode.

[MiMoHo]

Thanks @eranl, that's a fair correction and I stand corrected — I framed this as "the bar is navigation, not a tool", but the actual rationale in #1606 was about height/space consistency when the toolbar is hidden, not about what the bar is for. Sorry for mischaracterising it.

To keep the discussion grounded, I measured what this PR actually does on an emulator (Pixel-ish, 1080×2400, toolbar hidden, 100% emoji size), using the IME window's contentTopInsets:

Mode	Emoji view height	Category bar	Emoji rows
current hiding_global = false (bars shown)	893 px (= alpha kbd)	yes	~3
current hiding_global = true (default, no bars)	893 px (= alpha kbd)	no	~4
this PR	998 px (+105)	yes	~4

So you're right that this PR reintroduces a mode-switch height change — but only for the emoji view, and by exactly the category-bar height (~105 px). The clipboard view stays height-consistent (its bar now simply follows the toolbar). What the emoji view gains for that +105 px is: the full "no-bars" number of rows and the category bar, instead of today's either/or (bar + fewer rows, or more rows + no bar).

The reason I think that trade is worth it specifically for the emoji view: switching to emojis is usually a short, focused detour — you go there to pick an emoji and come back. In that moment, an extra visible row helps you find the emoji faster, and the temporarily taller keyboard is a very short-lived cost. It also sidesteps #2546, where a user simply couldn't find most emojis because, with the default settings, the only way to change category was swiping (which people don't discover). Relying on swipe-only navigation as the fallback is exactly what bit that user.

That said, I don't want to steamroll a deliberate decision, so it's really @Helium314's call. Roughly the options:

1. This PR as-is — category bar always shown as an on-top extension; emoji view is ~one row taller than the alpha keyboard, full rows preserved. (Accepts a height change, only in emoji view.)
2. Keep height constant — always show the category bar but let it eat into the grid (no height change, but back to ~3 rows). Fixes Can't find all list of emojis #2546's discoverability without the height jump, at the cost of a row.
3. Keep it configurable — but that's the setting this PR was trying to retire, so it adds back the complexity.

My preference (and the motivation from the linked discussion) is 1, because it's the only option that gives both discoverable category navigation and a full set of rows. But if the constant-height invariant is something you'd rather not break, 2 is a smaller change that still fixes the "can't find emojis" problem. Happy to rework the PR toward whichever direction you prefer.

[eranl]

Option 2 is already supported (the setting's default should possibly be changed to off, to prevent the issue you mentioned).
To make it totally configurable, you could replace the switch setting with a list setting with multiple options, but that could be confusing.
This feature has been out for over a year, so changing the way it works without an option, based on a single issue, seems problematic to me.