Should the presence of anchors overwrite or warn if they contradict set categories/subcategories?

I was investigating an [issue](https://github.com/googlefonts/ufo2ft/issues/938) compiling from a GlyphsApp source to UFO with fontmake and found that although I had anchors set in some glyphs, they would not generate the correct mark attachments down the line. To my surprise, the categories/subcategories set in GlyphsApp for some unencoded custom glyphs take precedence over what anchors are actually found in the glyph design.

e.g.:
- a `foo_bar` glyph was automatically categorized as "Letter"/"Combining" and would not receive mark attachment for `top` anchors; only when explicitly setting it to "Letter"/"Letter" would the attachment work
- a `foobar.calt` mark glyph was automatically categorized as "Mark"/"Spacing" and would not be included in markClass definitions despite having `_top` anchors; only when setting as "Mark"/"Non-spacing" would the attachment work

This was evident from the generated UFO `lib.plist` `public.openTypeCategories` as well as keys in the `glif` files.

Would it not make sense to at least warn, or even overwrite, those categories written to the UFO, if they are contradicting with the anchors found in those glyphs?

Where is the exact code for how categories/subcategories get sorted into base/mark openTypeCategories and is a straight mapping the best metric here, seeing as GlyphsApp "guesses" wrong or uses categories that contradict the anchors?

I'm thinking, simply:
- the presence of a underscored anchor should warn/fix if a glyph is not in the mark category
- the presence of an anchor should warn/fix if the glyph is not in the base category

Start by tracing the conversion code that writes public.openTypeCategories in lib.plist and category-related keys in glif files. Compare how GlyphsApp categories, subcategories, and anchors are handled for the examples in the issue. Done requires an agreed rule for warning or overriding contradictory categories, with behavior verified for underscored and regular anchors.

Written by the indexing model from the issue text.