test(ios): record every deliberate deferral where something checks it

Closes #118 — though not the way that issue proposed, and the difference is the point.

Why not capability_registry.zig

docs/ios-development.md said to declare the AR boundary there with a reason. That registry is desktop-only: 51 namespaces (tray, touchbar, appleScript, …), no mobile entry, and neither ios.zig nor ios_dispatch.zig reads it. Following the instruction literally would have meant inventing a mobile namespace in a registry the iOS build never loads — a declaration nothing consults, which is exactly the failure it was meant to prevent.

The boundary now lives in ios_conformance_test.zig, beside the ratchet, where the tooling that counts unmigrated actions can see it.

Why a table and not a comment

Both places these reasons previously lived have already rotted:

Prose does not fail. A list is only load-bearing if something breaks when it is wrong.

The anti-rot property, mutation-tested

The test asserts every row names a real spec action and one Zig still does not serve. Migrating a deferred action breaks the build until its row is deleted.

I did not take the passing test as evidence — I broke it both ways first:

listing `getDeviceInfo`  → exit 1, "Zig serves it now — delete the row, its reason is spent"
listing `notAnAction`    → exit 1, "which the spec's dispatcher does not have"

Deliberately not exhaustive

Twenty rows against a ratchet of twenty-five. This records deferrals with a reason worth keeping; an action in neither the table nor the modules is simply not done yet, which is a different and honest state. A second ratchet would only make that harder to say.

Two rows also carry corrections rather than restatements: StoreKit's is narrowed (StoreKit 1 is ObjC and bridge_iap.zig already drives it from Zig on macOS, so iOS is a product decision), and startVideoRecording's records that the spec's own success path has never run — see #115.

zig build test: 150/150 steps, 0 failures.