bug(web): mismatch between stub font and touch-layout font breaks font linkage for key-cap scaling

[jahorton]

Found this one while working on a user test for #10506.

We have a number of published keyboards in which the touch-layout has one setting/name for the keyboard's font while the package and/or stub uses a different name for the font. Details I've discovered:

1. It's the stub's name for the font that is actually used by KMW.
2. The keys, however, currently have style-settings that use the touch-layout name.
3. Key-cap scaling calculations... use the touch-layout name, not the stub's name.
4. If stub name != touch-layout name, the key-cap scaling function fails to find the font being used, instead basing key-cap scale on the default font, rather than the one KMW is using to display it!

Since we have a lot of keyboards out there with a mismatch, we probably need to ignore the touch-layout name entirely, using only the stub-name instead.

[jahorton]

A prime example of an affected keyboard: sil_euro_latin

Touch layout:

"font": "DejaVu Sans",

Actual stub from the KMW Cloud API:

"font": {
  "family": "LatinWeb",
  "source": ["DejaVuSans.ttf", "DejaVuSans.mobileconfig"]
}

LatinWeb will properly link the font - as that's what the stub calls it - while DejaVu Sans will not.

---

Attempts to investigate this lead me to a question - where does that LatinWeb bit even come from? I don't see any evidence of that string within sil_euro_latin.kps!