fix(docparser): anydoc 内嵌 EMF/WMF 图片的扩展名与 Rust 序列化器对齐，不再静默丢图

[linus-liu-web]

Description

Fix embedded EMF/WMF images being silently dropped when the anydoc engine parses a document.

anydoc renders an embedded image in place as ![alt](images/image-N<ext>). The <ext> comes from the Rust serializer (third_party/anydoc-go/src/asset_links.rs::extension_for). ImageResolver then looks that exact string up in a map keyed by anydoc.ImageDir + Asset.Name, where Asset.Name is built from internal/infrastructure/docparser/anydoc/backend_cgo.go::extensionFor. The lookup is an exact string match with no normalisation, so the two functions have to agree character for character.

They did not agree on EMF/WMF. anydoc emits image/emf and image/wmf for those parts (hard-coded in shared/assets.rs::media_type_for and shared/officeart.rs), the Rust table fell through to .bin, and the Go side asked the platform MIME registry instead of using a fixed table — so on a Debian image with media-types installed, /etc/mime.types supplied .emf/.wmf. The Markdown link and the ImageRef never matched, saveReferencedImage found nothing, and the image bytes were never stored. Nothing was logged and the document still reported success.

This change:

• adds image/emf and image/wmf to extension_for in asset_links.rs
• adds the same two media types to extensionFor in backend_cgo.go, and makes it a pure table

Dropping the mime.ExtensionsByType call is deliberate. Letting the host's /etc/mime.types decide the extension is what caused the divergence, and a table that has to mirror a static Rust table cannot depend on the runtime environment anyway. Unknown types fall back to .bin on both sides, which still satisfies the original goal of never writing an extension-less blob.

Verified reachable divergences before the fix, by reproducing extensionFor against every media type anydoc can produce:

media_type	Rust	Go
image/png, jpeg, gif, bmp, tiff, svg, webp	same	same
application/octet-stream, application/vnd.ms-ole-object	.bin	.bin
image/emf	.bin	.emf
image/wmf	.bin	.wmf

The other producers of images/... references derive the link and the map key from the same variable, so they cannot drift this way: builtin_converter.go::imageToResult uses one safeRef for both, and the Python parser writes image_path into the map and the Markdown together. The Rust/Go boundary was the only place where two independently built strings had to agree.

Type of Change

• 🐛 Bug fix

Related Issue

Fixes #3932

Testing

Added TestEmbeddedVectorImageLinksResolve, which builds a minimal .docx carrying one EMF and one WMF drawing in memory, converts it through the linked converter, and requires every Markdown image reference to resolve against the ImageRef map the resolver builds. It also pins .emf/.wmf, so agreeing on .bin for everything could not pass.

The test runs under the existing anydoc CI job (go test -tags anydoc ./internal/infrastructure/docparser/...).

Before/after on that fixture, with the archive rebuilt from this branch:

unfixed:  markdown "images/image-1.bin"  vs  refMap "images/image-1.emf"  -> no match
fixed:    markdown "images/image-1.emf"  vs  refMap "images/image-1.emf"  -> resolves

The test is not vacuous: pointing either table back at ".bin" turns it red with

markdown reference "images/image-1.emf" matches no ImageRef, so the image would
never be stored (lookup keys: [images/image-1.bin images/image-2.bin])

Also ran go vet -tags anydoc ./internal/infrastructure/docparser/..., go test -tags anydoc ./internal/infrastructure/docparser/... and go build -tags anydoc ./cmd/server.