Isolate embedded MD4C symbols and parser headers for coexistence #846

Bug summary

Enriched's embedded MD4C exports md_parse with its original global C name. An application that also links another embedded MD4C copy can fail with a duplicate-symbol error. On iOS, CocoaPods header maps can also resolve the bare md4c.h or MD4CParser.hpp includes in Enriched's Objective-C++ parsers to another dependency's headers.

This was encountered while integrating Enriched alongside Nitro Markdown in pingdotgg/t3code #12781. That integration subsequently removed Nitro; the current T3 sole-renderer configuration does not need this fix. This issue is about generic coexistence for other consumers.

Version and reproduction

Reproduced from current Enriched main, bb2b0942, using the shared C sources on Linux with GCC. The original integration used 1.1.0-nightly-20260918-bb2b0942a. This compiler diagnostic does not require React Native or a device.

cc -std=c99 -c packages/core/cpp/md4c/md4c.c -o /tmp/enriched-md4c.o
cc -r /tmp/enriched-md4c.o /tmp/enriched-md4c.o -o /tmp/two-md4c-copies.o

The linker reports multiple definition of md_parse. nm -g --defined-only finds md_parse as the only global defined symbol in the embedded MD4C object.

Proposed narrow fix

Map md_parse to enrm_md_parse in Enriched's own embedded header so both the C implementation and its callers use the same private name. Preserve that alias when scripts/fetch-md4c.sh refreshes the sources. Resolve Enriched's parser headers by explicit relative paths, which work both with the monorepo cpp symlink and the copied cpp tree in the published package.

I plan to submit a small PR with a diagnostic that compiles and links two complete MD4C copies, calls both parsers, and checks the bridge's C++ includes against conflicting headers. No public API, clipboard behavior, extension API, or rendering change is proposed. Native example-app testing remains a separate maintainer gate; I am not running devices or simulators from this contributor worktree.