i18n: Additional blocks not made translation-ready on theme save

[bph]

Following the pattern established by #735, #737, #742, #773, #744, #756, and the HTML-comment attribute mechanism added in #788, several core blocks with user-facing string content still aren't picked up by the "Localize Text" option on theme save.

This is a continuation of the band-aid approach acknowledged in #776 — the architectural fix is tracked there. This issue is just the punch list of remaining blocks that fit the existing mechanism (get_localizable_block_attributes and get_text_replacement_patterns_for_html in includes/create-theme/theme-locale.php).

JSON-attribute coverage gaps (small additions to get_localizable_block_attributes)

Block	Attribute	Notes
core/navigation-link	label	Visible menu item text. Only helps inline navigation; menus stored as wp_navigation posts are out of scope here.
core/navigation-submenu	label	Same as above.
core/home-link	label	Default "Home".
core/social-link	label	Custom label override per icon.
core/categories	label	Dropdown label when displayAsDropdown is true.

Larger gap (needs a different mechanism)

• core/file — downloadButtonText and fileName are rich-text-sourced attributes stored in inner HTML, not in the block-comment JSON, so the attribute path doesn't reach them. This needs handling similar to the figcaption/alt cases in get_text_replacement_patterns_for_html.

Out of scope here

• The architectural rewrite tracked in Consider the ideal approach for text localization #776.
• Any block whose translatable text comes from dynamic data (post titles, taxonomy terms, etc.) — those translate via core, not via theme.json/templates.

cc @mikachan @scruffian @t-hamano for visibility (active on #776).

[bph]

PR #826 covers the five JSON-attribute additions (navigation-link, navigation-submenu, home-link, social-link, categories).

Leaving this issue open after that merges to track the remaining core/file work — downloadButtonText and fileName are rich-text-sourced (stored in inner HTML, not in the block-comment JSON), so they need handling in get_text_replacement_patterns_for_html rather than the JSON-attribute path.