fix(settings): Add default text to several l10n.getString calls

[LZoog]

Because:

• We must provide fallback text when pulling strings from Fluent since at the moment, we don't deploy en/en-US strings and rely on fallback text

This commit:

• Adds the default text to several l10n.getString calls, updates some tests

fixes #12857
fixes #12858
fixes #12859

---

I started adding tests for all of these and then realized we were missing quite a few and some tests might take a bit longer to write. If you see something in particular feel free to call it out.

At the time of writing, without further investigation I don't know why these ever rendered correctly, we've been relying on fallback text for English for all of our strings and we even had tests to check for FTL IDs rendered rather than the English text.
Edit: see comment

This makes me eager to work on this spike, I think there's some l10n improvements we can make all around.

[LZoog]

I spent a few minutes trying to get some of these .toBeInTheDocument tests changed to .toBeInTheDocument() but I don't know why they're failing. I'll file a follow up issue to check all of our toBeInTheDocument and toBeTruthy calls across React tests because we have a few like that for some reason, which makes the tests look like they're passing when they aren't necessarily.

[LZoog]

follow up: #12868

[vbudhram]

@LZoog Not sure why this broke?

[vbudhram]

Probably needs a .

[pdehaan]

@LZoog Possibly this?

fxa/packages/fxa-settings/src/components/UnitRowRecoveryKey/index.tsx

Line 34 in af5e635

alertBar.error(l10n.getString('rk-remove-error'));

I've been trying to go through every result from git grep -n "l10n.getString" packages and verify it has 3 parameters, but wondering if there is a better way. Not sure how we could use a linter to enforce a method has 3 args (unless we do a lot of very scary AST work).
Or my cheaper solution of wrapping l10n.getString (which comes from @fluent/react's useLocalization() function) with a custom helper which just throws a hard error if the fallback string is undefined.

[LZoog]

@LZoog Not sure why this broke?

@vbudhram I'm actually not sure why it was ever working. 😭 But I really wonder that too. It was always broken in Storybook. I don't see any changes in this train that would have caused it, or any changes on the l10n side.

@pdehaan Ah nice find, I'll add the default text for that one too.

Or my cheaper solution of wrapping l10n.getString (which comes from @fluent/react's useLocalization() function) with a custom helper which just throws a hard error if the fallback string is undefined.

This is a good idea if we want to keep relying on fallback text, I'm going to add a comment to that spike (those are becoming my famous last words).

[LZoog]

I think I've sorted out why this happened.

#12778 landed last train, which introduced a more correct Fluent strategy for Settings. I think prior to that fix, the entire page was rendering the strings from the en-GB bundle, since it was the closest available matching, as we don't have an en or en-US bundle and rely on fallback text for English (US, anyway) users. Fluent couldn't find the en or en-US bundle and didn't have fallback text supplied, so it returned the fluent IDs instead.

FWIW, we have had other conversations around making our l10n approach consistent across packages as well as improvements, including potentially not relying on fallback text at all for React applications (we'll weigh pros/cons), in this spike.