Case corrections of translations are refused as duplicates because the translation column lost its binary collation

Problem/Motivation

Drupal 7 stores l10n_server_translation.translation with binary = TRUE, so the column has a binary collation and translations are compared case sensitively. l10n_community_add_suggestion() relies on it: 'Use BINARY matching to avoid marking case-corrections as duplicate'. On 3.0.x the field is a plain string_long base field, the column ends up as utf8mb4_general_ci, and L10nPo::addSuggestion() compares with a regular equality condition. Suggesting 'Menü' where 'menü' already exists is therefore reported as '1 duplicate translation not saved' and the correction cannot be entered at all.

Steps to reproduce

1. Suggest 'ez egy teszt.' for a string.
2. Suggest 'Ez egy teszt.' for the same string.
3. 3.0.x: '1 duplicate translation not saved'. Drupal 7: '1 suggestion added', two records.

Proposed resolution

Declare the column binary in L10nServerTranslationStorageSchema like Drupal 7 does. Searching inside translations becomes case sensitive too, which is how Drupal 7 behaves.

Covered by testCaseSensitiveSuggestions() in the Drupal 7 test class (#3621196 branch) and its port in L10nSuggestionsTest, which fails without the schema change.

Remaining tasks

User interface changes

API changes

Data model changes

l10n_server_translation.translation changes from utf8mb4_general_ci to utf8mb4_bin. Existing rows are kept.

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.