2.2.1 - links next to another Rust library in a host with Objective-C and C++

Fixed

• A host with its own Objective-C and C++ links again next to LibDovi (AetherEngine#752). The prelink step made every symbol except the C API local, including rust_eh_personality. A local copy still counts as a second personality routine in the final image, and compact unwind can encode at most three per image. LibDovi's copy plus this one plus the host's __objc_personality_v0 and __gxx_personality_v0 made four, and ld stopped with "Too many personality routines for compact unwind to encode". rust_eh_personality is now exported as a weak definition, so the linker keeps a single copy: another Rust library's strong one if present, otherwise this one. Panics still never leave the library. Every exported function catches them, and only the routine that reads the unwind tables is shared. truehd_atmos_selftest confirms the catch in the final link.

Verification

• With LibDovi 2.1.0 and an Objective-C and C++ host, 2.2.0 fails to link for tvOS, the tvOS simulator, iOS and the iOS simulator (x86_64), and 2.2.1 links for all four in both link orders.
• harness/verify.sh gained a check that links the macOS slice next to a second Rust static library in an Objective-C and C++ host, in both link orders, and catches one exception in each of the four runtimes. That check fails against the 2.2.0 binaries.
• The rest of verify.sh passes in full, with PCM bit-exact against truehdd on every sample and fixture.

Same decoder, same C API (API version unchanged), same slices and minimum OS versions. The only new global symbol is the weak _rust_eh_personality.