Synchronize native permission settings with Rust grants and revocation

Permission settings must read and update the same effective decisions used by the Rust runtime. Today iOS Apps settings uses the legacy permission repository, while Rust can retain a separate persisted grant or denial. A user can therefore revoke access in Settings and still have a later Rust-authorized request allowed.

This is a follow-up to #794 and #795 and is intentionally outside their network/permission compatibility fixes.

Current failure

1. A product receives a permanent Remote or device permission through the Rust runtime. The native callback may consult legacy consent, and Rust persists the result in its core storage.
2. The user revokes that permission in Apps settings. AppPermissionsInteractor.revokeOnDisappear updates ProductPermissionRepository only.
3. A later checked operation resolves the saved Rust grant and can proceed without consulting the changed legacy entry. Conversely, a cached Rust denial can survive a legacy grant/reset, and Rust-only decisions need not appear in Settings.

This concerns successive operations and does not require interacting with Settings while a permission modal is open.

Implementation scope

• Establish one durable permission authority exposed to both runtime enforcement and native settings. Define the transition for existing legacy users.
• Wire permission listing, grant/deny changes, revocation, product reset and removal to that authority.
• Migrate existing grants and explicit denials using Rust domain normalization/wildcard semantics, with a deterministic conflict policy that does not silently broaden access.
• Ensure revocation/reset also handles outstanding in-memory AllowOnce grants in affected live executions. Temporary grants must remain execution-scoped and must never become durable during migration.
• Preserve notification cancellation when its permission is revoked, and distinguish product consent from OS permission availability.
• Define whether existing streams/connections continue after revocation; future checked operations must use the updated decision without requiring a product restart.

Acceptance criteria

• A permission granted through Rust appears correctly in Apps settings.
• Revoking it in Settings prevents a subsequent checked operation from reusing the old Rust grant, including an already-open product execution.
• Resetting a denial permits a fresh permission request instead of leaving an invisible cached refusal.
• Product reset/removal clears both durable decisions and applicable live one-use grants.
• Migration is repeatable, preserves explicit refusals, and handles normalized/wildcard keys without silently increasing access.
• Existing tests cover both legacy-origin and Rust-origin consent, revocation, denial reset, relaunch and temporary-grant cleanup.

Relevant code

• Settings reads and revokes legacy grants
• Legacy permission repository
• Native Rust permission callbacks
• Rust permission state and one-use grants

Related: #821 discusses product-facing permission queries. This issue addresses native settings, persistence and migration independently of its proposed launch-time consent model.

Start by reading AppPermissionsInteractor.swift, ProductPermissionRepository.swift, RustProductExecutionBridge.swift, and rust/crates/truapi-server/src/host_logic/permissions.rs to map legacy and Rust permission state, normalization, and one-use grants. Define the shared authority and migration behavior, then add coverage for both consent origins, revocation, resets, relaunches, wildcard keys, and temporary-grant cleanup until the listed acceptance criteria pass.