docs: distinguish create-vs-apply customizations for variants in language table

[shirgoldbird]

Note

Stacked on #395 (base branch is docs/language-table-from-v3). Once #395 lands, the base flips to main and the diff will show just the FeatureBadges change.

What

Carries forward the one still-useful piece of the now-closed #327 into the generated-table world of #395.

Glossaries and style rules are created for a root language (e.g. EN) but apply when translating into its variants (e.g. EN-GB) — you can't create them for a variant code. The current table shows a flat green Glossaries badge on variant rows, which reads as "you can create a glossary for EN-GB."

This PR renders glossary/style-rule support on variant rows as an orange "Translation: Glossaries" / "Translation: Style Rules" badge with an explanatory tooltip, matching the existing "Translation: Target Only" convention #395 already uses for variants. Root-language rows are unchanged (green Glossaries / Style Rules).

Why this instead of reopening #327

#327 hand-edited the static languageData array (adding translateGlossaries/translateStyleRules flags). #395 makes that array generated from GET /v3/languages with a daily sync workflow, so those edits would be overwritten. This change lives entirely in the FeatureBadges component, outside the BEGIN/END GENERATED markers, so the generator never touches it.

The create-vs-apply concept is also now documented in How to Apply Customizations to Language Variants; this just makes the table consistent with it.

Open question for @lilkraftwerk

The generated data currently has all variants at glossaries: true but styleRules: false (each /v3/languages resource list taken literally). The customize guide says root style rules apply to variant targets too (using-style-rules.mdx: "a list with language: \"en\" works for EN-US and EN-GB targets alike"). So today only the Glossaries apply-via-root badge actually renders on variants; the Style Rules branch is symmetric and correct but inert until the generator marks style-rule support on variants. Worth deciding whether the generator should reflect that — separate from this rendering change.

Test plan

• mint dev — variant rows (e.g. EN-GB, PT-BR) show an orange "Translation: Glossaries" badge with tooltip; root rows (e.g. EN, DE) still show green "Glossaries"/"Style Rules"
• Re-run node scripts/generate-language-table.mjs <key> and confirm it only rewrites the languageData array, leaving FeatureBadges intact

🤖 Generated with Claude Code

[shirgoldbird]

cc @BriannaDelgado @lilkraftwerk

Context on how this PR came together:

• @BriannaDelgado — this carries forward the still-useful piece of your fix: Improve clarity around customizations' supported languages #327 (the create-vs-apply distinction for variants). fix: Improve clarity around customizations' supported languages #327 itself was closed because its concept is now documented in the Customizations for Variants guide and its static table edits were superseded by @lilkraftwerk's Generate supported-languages table from /v3/languages #395, which generates the table from GET /v3/languages. The badge idea lives on here.

• @lilkraftwerk — this is stacked on Generate supported-languages table from /v3/languages #395 and touches only FeatureBadges (outside your BEGIN/END GENERATED markers), so the generator/daily sync won't overwrite it. One thing for you to weigh in on: the generated data has all variants at glossaries: true but styleRules: false, while the customize guide says root style rules apply to variant targets too. So today only the "Translation: Glossaries" badge renders on variants; the style-rules branch is inert until the generator marks style-rule support on variants. Is that an intentional reflection of what /v3/languages reports per resource, or should the generator derive variant style-rule support from the root language?