docs: explain Rust-owned publication exports

[Iktahana]

What changed

• rewrite the English, Japanese, and Traditional Chinese publication guides so they describe the current Rust-owned EPUB, DOCX, export-profile, page-size, and PDF print-data implementation
• clarify that JavaScript remains a thin compatibility and host layer, and that future Python, Swift, and Android bindings can expose the same Rust behavior without reimplementing it
• update package READMEs, Rust API status, CLI guidance, Python binding limitations, and contributor contract-test instructions
• document the release gate: unit and coverage jobs complete before DOCX, PDF, EPUB, and HTML publication contracts
• improve reader-facing wording, correct stale links, and use Markdown highlighting for the homepage MDI example

Why

The previous documentation still described configured EPUB/DOCX as JavaScript publication-adapter work and listed Rust profile support as pending. That no longer matched the implementation and could lead users—and future binding authors—to build against the wrong ownership model.

User and developer impact

Readers now get one consistent explanation across all three languages: Rust validates publication profiles and generates EPUB/DOCX, while hosts only handle platform concerns such as launching Chromium. Python’s current limitation is described accurately as an unexposed wrapper API rather than missing Rust functionality.

Validation

• pnpm typecheck
• pnpm docs:build — 392 pages built
• pnpm --filter @illusions-lab/mdi test — 32 tests
• pnpm --filter mdast-util-mdi test — 25 tests
• local-link audit across 38 changed prose files
• stale publication-ownership phrase audit
• git diff --check

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!