postscriptBlueValues are not written for UFOs extracted from a Glyphs file if the overshoot value has wrong polarity

Extracting UFO masters/instances from a Glyphs file where some overshoots are defined with the wrong polarity the exported UFOs are missing `postscriptBlueValues` entirely.

E.g. these master metrics values would cause this (rightly so, I suppose):

```
Cap Height 700 -15 (should be positive overshoot for zones above 0)
Descender -250 15 (should be negative overshoot for zones below 0)
```

Instead of silently dropping the `fontinfo.plist` `postscriptBlueValues` entry, I'd expect a warning. I couldn't pin point where exactly in the compile stack this assertion kicks in.

Attached a file where `fontmake -g Test-PostscriptBlueValues-Fails.glyphs -o ufo `will result in two masters, the `master_ufo/TestfontPostscriptBlueValueFailing-Black.ufo/fontinfo.plist` correctly with `postscriptBlueValues`

And `master_ufo/TestfontPostscriptBlueValueFailing-Thin.ufo/fontinfo.plist` missing the entry. (The same applies to the instances when ran with `-i`).

I'd expect:
- a warning or, preferably, failing with a descriptive error
- other, valid, zones to be compiled and resulting in a `postscriptBlueValues` entry (just one erroneous overshoot will cause all zones to be dropped)

[Test-PostscriptBlueValues-Fails.glyphs.zip](https://github.com/user-attachments/files/20688517/Test-PostscriptBlueValues-Fails.glyphs.zip)

Run `fontmake -g Test-PostscriptBlueValues-Fails.glyphs -o ufo` with the attached file and compare the two generated `fontinfo.plist` files, then repeat with `-i`. Trace the Glyphs-to-UFO compilation path where `postscriptBlueValues` is produced. Done means invalid polarity is reported descriptively and valid zones are not silently discarded.

Written by the indexing model from the issue text.