No matter how you do it, if it's submitted to KDP (epub is best according to Amazon speaking to me) and the there are too many "body fonts" (we don't know how Amazon measures this?) then Amazon might strip all the embedded fonts.
Actual azw3 files by USB to a Kindle on your desk don't have the same limitations as azw3 from Amazon publishing or "Send to Kindle". Also big publishers have a different way of interfacing to Amazon.
The KFX is different:
1) Actual downloads from Amazon for transfer by USB to eink are never KFX. Only old mobi or azw3 depending on model. Maybe the PW1 has something weirld with images? I'm not sure.
2) All Whispernet downloads for apps or Kindles that can support KFX are KFX.
3) Calibre can make azw3, but not KFX, the KFX output plugin invokes command line version of an Amazon program (I forget which one), which doesn't work on Linux.
4) KFX has different rules to AZW/KF7 and seems mainly to exist to reduce Whispernet traffic on Mobile, allow reading before download is complete and always have DRM even if publisher said no DRM.
The italic and bold variation of existing body font (as per css of the p) should be inline HTML. So an occasion where "direct formatting" in the wordprocessor works. Using a character style (which will map to additional CSS) may not work. The only other direct formatting would be superscript and subscript. It sort of makes sense that bold, italic, superscript and subscript that are using the existing body CSS are inline HTML. The actual opening <p should reference a CSS class if needed, or there can be a default p CSS.