Track intentional iOS Zig/Swift validation divergences in a checked-in conformance table

Follow-up to #117 after the product decision to keep stricter, fail-closed Zig behavior. The SDK compatibility guide documents the classes of differences and the bridge modules explain many individual choices, but the original audit claimed ~38 per-action cases without checking in its list. Do not infer or reproduce that count without evidence.

Create a checked-in, reviewable table keyed by action and malformed or conflicting input: expected Zig error or result, observable legacy Swift behavior, and source/test references. Add a conformance test that validates action names and checks cases exercisable without a simulator; identify cases requiring a real device separately. Cross-link docs/api/mobile/runtime-compatibility.md. This is about audit coverage, not weakening Zig validation or changing successful reply shapes.

Implemented on main: docs/api/mobile/ios-validation-conformance.md is the checked-in action/input/result table, linked from runtime-compatibility.md; scripts/ios-validation-conformance.test.ts and the Zig conformance gate validate action names and evidence paths. The current rows explicitly preserve stricter Zig behavior (including path-traversal and embedded-NUL rejection) rather than weakening it. This issue is ready for closure after maintainer review.

Resolved on main by the checked-in iOS/Swift conformance table and validation tests. The intentional divergences, including stricter path validation, are now documented and covered. On main, unreleased.