[Refactor/Chore] Normalize legacy emoji IDs on the backend and remove the frontend compatibility map

Start by inventorying emoji-bearing fields and boundaries, then inspect emoji-legacy.json and the AppIcon, AnswerIcon, favicon, and picker preview consumers named in the issue. Define and test the normalization and migration contract, including imports and mixed-version paths. Done means legacy and Unicode icons work throughout rollout, focused migration/import/rendering tests pass, and the frontend map is no longer downloaded.

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for refactors or chores; questions belong in Discussions.
• I have searched for existing issues, including closed ones.
• I confirm that I am using English to submit this report.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• I have preserved the template sections and filled in the required fields.

Description

Follow-up to #42435 and the Frimousse migration in #42469.

The migration renders Unicode emoji directly and uses a synchronous emoji-legacy.json compatibility map for previously persisted Emoji Mart IDs such as rabbit and robot_face. New picker selections already emit Unicode. This preserves old icons without requiring an immediate database migration, but every consumer of the resolver still includes the compatibility map even when its icon is already Unicode.

Explore normalizing legacy emoji IDs at backend boundaries and migrating stored icon values so the frontend can eventually render Unicode without shipping the legacy map.

Proposed scope:

• Inventory emoji-bearing fields and nested icon metadata across apps, published/shared app data, datasets/pipelines, tools, and other affected consumers. Distinguish emoji values from image IDs, URLs, and other icon types.
• Define one backend normalization contract for legacy IDs, aliases, Unicode, and unknown values. Preserve Unicode sequences, including variation selectors, skin tones, and ZWJ sequences.
• Apply normalization at relevant API read/write and DSL/template import boundaries so old exports and clients cannot reintroduce unhandled IDs after migration.
• Provide an idempotent, upgrade-safe data migration with an explicit rollout and rollback strategy. Do not remove frontend compatibility until all supported data sources and mixed-version paths are covered.
• Remove the frontend compatibility map and simplify AppIcon, AnswerIcon, favicon, and picker preview consumers once that contract is established.

Acceptance criteria:

• Existing legacy icons and newly selected Unicode icons render correctly before, during, and after rollout.
• Old DSL/template imports remain supported; image/link icons and unknown values follow an explicit, tested policy.
• Focused tests cover normalization, migration idempotency, import compatibility, and frontend rendering/SSR behavior.
• Production builds using the same configuration demonstrate the change in app-list and Knowledge-list dependency closures. Report actual bundle/transfer differences without treating raw JSON size as guaranteed savings.
• Ordinary frontend emoji display no longer imports or downloads the legacy ID map.

Motivation

Keep persisted icon values independent of a particular picker library and remove transitional compatibility data from frequently visited frontend surfaces. The synchronous frontend map is a reasonable migration bridge; this issue records the broader backend work needed to retire it safely, rather than expanding the current picker PR.

Additional Context

At the time of #42469, the map covers 1,870 Emoji Mart IDs and 61 aliases. Its JSON is approximately 43.2 KB after removing whitespace and 15.0 KB when gzipped independently; these are file measurements, not measured production bundle increments.

The selector's separately hosted Emojibase data (approximately 94 KB gzip) is fetched when the picker opens and is outside this follow-up's removal scope.

An alternative is importing upstream emojibase-data@17.0.0/en/shortcodes/iamcal.json. Local comparison covered all 1,931 current keys, with 215 variation-selector differences requiring careful handling. That would reduce ownership of a custom data snapshot, but would still ship a shortcode map and would not achieve the frontend-removal goal above.