feat(odf): decode flat xml OpenDocument files

[andiwand]

.fodt, .fodp, .fods and .fodg were only extension and mimetype aliases on the zip-backed rows. The table therefore promised open, translate_html, edit and save for a file that in fact fell through to the xml source view — and a host that trusted the extension and named the type got NoOpenDocumentFile instead. This makes the promise true.

How

A flat document's one office:document root carries what content.xml and styles.xml carry between them, so odf::Document gains a constructor that hands that root in as both roots. Everything downstream — parse_tree, StyleRegistry, list numbering, the adapter — is the existing code, shared with the packaged path via a new init_.

Recognition rides on the parse xml::XmlFile already did, right next to svg's: the root element is the only thing that tells either from any other xml. is_flat_opendocument_file reads it off that tree; FlatOpenDocumentFile then reparses with the document parse options, which a source view's (parse_full | parse_ws_pcdata_single) cannot substitute for — whitespace-only pcdata is text in one and nothing in the other.

Without a package there is no filesystem, so two things differ:

• Images come base64 encoded in office:binary-data. The adapter decodes them lazily, and does so in a package too, where they are equally legal but were previously reported as external.
• save re-serialises the one tree instead of rebuilding a zip.

Flat files are never encrypted, so decrypt throws NotEncryptedError.

Verification

Ten unit tests on inline flat-xml literals cover the four types, the recogniser (including what must not open as flat), tree and style resolution from the single root, embedded and linked images, and the save round-trip.

Beyond that, LibreOffice's own flat export of eleven files across the four types was rendered and compared against the packaged render of the same source:

	packaged	flat	images
about.fodt	635 lines	635	png + jpeg, 85084 B both
image-text-wrap.fodt	596	596	8 png, 4633120 B both
table-span.fodt	634	634	identical output
mixed-layout.fodt	590	590	identical output
style-various-1.fodt	683	683	png, 100792 B both
image-1.fodp	635	635	png, 24876 B both
presentation-yunation.fodp	1198	1198	12 png + jpeg, 7014156 B both
style-various-1.fodp	732	732	—
file_example_ODS_100.fods	3624	3624	—
draw.fods	909	909	—
sample.fodg	1183	1183	—

Image payloads are byte-identical throughout. The remaining line differences trace to LibreOffice's export, not to the decoder — e.g. it writes svg:stroke-color="#000000" draw:fill-color="#99ccff" into the default graphic style that the packaged file does not have.

Full suite: 995 passed, 0 failed, 8 skipped (the usual svm/wpd ones).

Follow-up, not in here

The corpus in OpenDocument.test has no flat files, so html_output_test gives this no pinned reference coverage. Adding one file per type there plus a pin bump is the natural next step — happy to do it as a stacked change if you want it.