Expose the already-parsed text:outline-level as headingLevel, not just re-encoded into styleId

[Mearman]

Companion to ExaDev/document-schema.js#13, which proposes a canonical headingLevel?: number field on ContentParagraph. This is the odt-side work, and it's the smallest of the three format changes that issue names — the number is already being read.

src/typed/odt/read.ts already extracts the real text:outline-level attribute off text:h (with the ODF-spec default of 1 when absent, and graceful degradation on a malformed value) — but it currently only uses that number to build the docx-equivalent styleId string ('Heading' + level), then discards the number itself. Once headingLevel exists on the shared schema, populate it directly from the same already-parsed value, alongside (not instead of) the existing styleId encoding.

Blocked by ExaDev/document-schema.js#13 landing the field itself first.

[Mearman]

Done in #54: readParagraphOrHeading now keeps readOutlineLevel's parsed text:outline-level number as ContentParagraph.headingLevel alongside the unchanged 'Heading' styleId encoding, so both derive from the same single parse. The kitchen-sink and minimal fixture tests assert both fields on every heading. That PR also carried the document-schema.js ^3.0.0 migration (dep-only for odf.js) and the formula test's formatVersion literal switched to the imported CONTENT_FORMAT_VERSION constant.