Tauri 2 capability files: limits of build-time permission scoping across desktop and mobile targets

Goal

I am designing the permission layout for a Tauri 2.x app that shares one codebase across desktop (Windows, macOS, Linux) and mobile (iOS, Android). The goal is a single, maintainable capability configuration that grants each plugin only what it needs, without over-privileging any target.

Constraints and uncertainty

From the documentation, capabilities are declared in JSON files under src-tauri/capabilities/, validated at compile time, and can be scoped to specific windows. Permissions such as fs:allow-read-text-file are plugin-defined, and omitting an entry means the command simply is not available.

What is unclear to me is how far this model actually goes in practice. Some desktop-oriented permissions (raw filesystem paths, arbitrary shell execution) appear to have no real equivalent under iOS and Android sandboxing, and permission granularity for things like clipboard or notifications seems to differ per platform. I also understand there is no runtime prompt API on desktop — access is fixed at build time — while mobile OSes may still demand their own entitlement or user prompt on top of the capability file.

Questions

1. Is a single shared capability file realistic for desktop plus mobile, or should platform-specific capability files be split per target?
2. When a permission has no mobile equivalent, does the build fail, or does the command fail silently at runtime?
3. Is there any supported way to request elevated access at runtime on desktop, or is rebuild-and-redistribute the only path?