Personally, I would start with building an application that uses a c xml library to read the xml and generate the optimized internal representation that is hopefully a lot smaller, looking at what is possible to reduce the size.
Then you can use that as a build step to generate the data and include it in the build, here is a simple example of that Zig Build System ⚡ Zig Programming Language
Then optionally you could later expand that (on platforms where it is supported), with something that allows you to, instead of embedding the data directly, put it into a dynamic library that you can dynamically link, or alternatively use memory mapping to map a file, or use a file read to read it. For cases where you would want to update the file while the application is running, without recompiling it.
I don’t know how feasible that would be on the more memory constrained devices, but maybe you could instead have something which connects to those and carries out the update, by either replacing the full application, or patching the running application, if you can figure out how to do that (if you do let us know).
I don’t think comptime fits this usecase, I would especially avoid dealing with XML parsing at comptime, instead I would transform the xml into something less verbose, intern strings for attributes/tags you can’t get rid of (if they are used too randomly/sporadic) and eliminate strings where possible (for example by making them required struct fields, which compile down to an offset), generating enums for repeating values or tags, attributes, etc. A whole other research part would be to explore different compression methods.
The link also has an example for generating source code (next section), you could use that to also generate the code that is used for using/reading the data you generated from the xml.
I think the encoding doesn’t matter that much, unless you have specific requirements, for example if you want to use utf-8 internally then it would probably be helpful to already convert it to utf-8 when you are reading the xml.
But if you have no reason to change the encoding you could keep it as is (at least I think so, are there other concerns you have about the encoding?).
I guess the xml parsing might need to deal with some details about the encoding, I am not exactly sure whether xml libraries support arbitrary encodings or only specific ones. Maybe you can specify more what your constraints are related to encoding, e.g. is the code required to use ISO-8859-1? If so changing it to utf-8 and back might be not worth it. Also keeping it in ISO-8859-1 might make the data more compact, because utf-8 has more (unused) possibilities.