MEI encoding only fills coordinates for first/some staves; remaining <zone> elements have @ulx, @uly, @lrx, @lry all set to 0

NOTE: this is produced from work done on the **Bach Project**. I'm uncertain if this behavior has been encountered on previous medieval music manuscript approaches. @JoyfulGen @yinanazhou , y'all might know if something similar has happened previously...

I'm encountering an issue with the MEI conversion process where only the first staff in the input JSOMR file is correctly rendered in the MEI output. The converter is generating the correct number of elements (matching the number of staves), but only the first contains valid coordinate data. The remaining elements have all coordinate attributes (ulx, uly, lrx, lry) set to 0.

🧾 Input:
1. A valid JSOMR file that contains:
- Multiple staves, each with bounding_box, num_lines, and line_positions
- Corresponding glyphs, with pitch and bounding box information
2. A csv MEI mapping file

This will be done in Rodan, either directly into the `MEI Encoding` job, or on Rodan Production importing the `E2E 2nd branch only` to test staves only, or in the `e2e no text - stave troubleshooting` workflow. You will need the image L1 and L2, the NIC training file, and the MEI CSV mapping file.

`e2e no text` is the standard procedure and will produce a JSOMR file which will result in an incomplete MEI file. 1E2E second branch only` will require a fixed JSOMR file as input (see below), and the L2 png.

🐛 Bug behavior:
- MEI file contains multiple tags
- Only the first has correct coordinate data and appears in the output
- The rest of the tags have:
``````
- These zones are not referenced by or elements

✅ Expected behavior:

- All staves from the JSOMR file should be represented in the MEI output
- Each should reflect the bounding_box of the corresponding staff
- Each in the MEI should link to its respective via the facs attribute (as a note, staffDef isn't produced correctly either!)

### MEI Files
MEI file produced directly from `Miayo Staff Finding` into `Heuristic Pitch Finding`, which produced a JSOMR which was then used as an input into the `MEI converter` job renders a number of items only as zones, setting their coordinates equal to 0, rendering invalid for later editing in Neon and thus removing them.

the file `updated_output.mei` is an MEI file which was produced by using a script to compare the JSOMR produced by a polygons-to-JSOMR script (see #1291 ) to the Miyao-Heuristic-MEI produced MEI file, and filled in the relevant coordinates. The coordinates are correct and render appropriately in Neon.

.mei files aren't allowed to be attached here, so I've converted them to .txt.
Rodan produced:
[test_MEI Encoding - MEI_4 stafflines_standard no text copy.txt](https://github.com/user-attachments/files/20109894/test_MEI.Encoding.-.MEI_4.stafflines_standard.no.text.copy.txt)

JSOMR-MEI checked:
[updated_output copy.txt](https://github.com/user-attachments/files/20109895/updated_output.copy.txt)

### JSOMR files
Rodan produced:
[Miyao Staff Finding - JSOMR(3).json](https://github.com/user-attachments/files/20110048/Miyao.Staff.Finding.-.JSOMR.3.json)
Polygon produced (note: stave info only):
[output_interpolated_lines.jsomr17.json](https://github.com/user-attachments/files/20110041/output_interpolated_lines.jsomr17.json)

### Image Files
This has been tested using Bach Chorale107. Score image PNG and the separated staff layer are below.
Cho107 : 
Cho107 L2: 
Cho107 L1: 

### NIC Train File and MEI mapping file
NIC training input (converted to txt; convert back):

[Interactive Classifier - GameraXML - Training Data(1).txt](https://github.com/user-attachments/files/20110154/Interactive.Classifier.-.GameraXML.-.Training.Data.1.txt)

MEI CSV Mapping: [csv-square_notation_neume_level_newest (1)(1).csv](https://github.com/user-attachments/files/20110156/csv-square_notation_neume_level_newest.1.1.csv)

If you have any questions about attachments etc, please don't hesitate to holler.