bug: Regular i-family glyphs rise 1 px above the baseline at 18 ppem

D2Coding 1.3.3 Regular renders three related glyphs one pixel above the baseline with native FreeType hinting at exactly 18 ppem:

This looks like a remaining part of #70. That issue reported the same visible problem with i at 18 pt, and the 1.3.2 release notes say it was fixed. The 1.3.2 update added some instructions to Regular i, but its lower stem still has matching -1 px DELTAP corrections at 19 and 20 ppem with no correction at 18 ppem. The equivalent Cyrillic glyph programs were unchanged.

The missing corrections are:

• i: points 2 and 5
• uni0456: points 2 and 5
• uni045D: points 9 and 16

For each point, the existing packed values encode the same -1 px correction at 19 and 20 ppem. Adding the corresponding value for 18 ppem keeps the glyph on the shared baseline.

I tested that change against both Regular TTFs. The three isolated baseline lifts dropped to zero, and only the affected glyph programs changed. Bold already renders these three glyphs on the baseline at 16-20 ppem.

The static scan finds many DELTAP gaps that do not cause a raster defect, so I only treated a glyph as affected when the missing delta coincided with an isolated 18 ppem lift. In Regular, that reduced 359 static candidates to these 3 raster-confirmed cases.

Test environment:

• FreeType 2.13.2 with native grayscale hinting
• D2Coding 1.3.3 Regular SHA-256 fdd2b06844f9e936390d5c8e47355156954098d41debf1b191a9bfbf272836d0

I can send a PR that updates the three Regular UFO instruction sources, both shipped Regular TTFs, and adds a 16-20 ppem raster regression check for all four builds.

Before

After

Locate the three Regular UFO instruction sources and both shipped Regular TTFs, then inspect the existing DELTAP programs for the named points and ppem values. Reproduce the 16–20 ppem raster behavior with native FreeType, apply the missing 18 ppem corrections, and verify that all four builds keep the three glyphs on the baseline without unrelated changes.