Tauri 2.0 window capabilities inheritance unspecified for child windows without inherit flag

Migration from Tauri 1.x allowlist to Tauri 2.0 capability-based security requires per-window capabilities defined in configuration. The documented model moves permissions from global allowlist to capabilities and plugins structures, with distinct defaults for security.csp and window data handling.

The precise goal is to determine predictable permission behavior for nested windows created from a parent window that holds specific scopes such as fs read or http. Documentation references capability inheritance for nested windows but does not specify the default when the inherit flag is omitted.

This creates uncertainty about whether a child window automatically gains parent scopes, is denied by default, or requires explicit capability assignment. Clarity is needed for configuration transition and compatibility boundaries between Tauri 1.x and 2.x security models.

Does a child window created without an explicit inherit flag automatically receive the parent window's fs or http scopes in Tauri 2.0? Is inheritance opt-in only, or is there a default deny with platform-specific variation? Which scopes, if any, are documented as implicitly propagated versus explicitly required?