feat(ipc): hardened sessioned JSON-RPC IPC (WebSocket + NamedPipe)

[Copilot]

This pull request introduces a comprehensive and security-hardened IPC (Inter-Process Communication) subsystem for the Files application, focusing on resource protection, authentication, and correctness. The changes include strict JSON-RPC 2.0 validation, encrypted token storage with epoch-based rotation, centralized method registry, rate limiting, lossy message queuing, and serialization of UI operations. Additionally, the configuration is now centralized and adjustable, and several new core components have been added to support robust remote control features.

IPC Framework & Security Enhancements

• Added strict JSON-RPC 2.0 validation and shape enforcement via the new JsonRpcMessage class, ensuring only valid requests and responses are processed.
• Implemented DPAPI-encrypted token storage with epoch-based rotation in ProtectedTokenStore, invalidating sessions upon token rotation for enhanced security.
• Introduced ClientContext for per-client state management, including token bucket rate limiting, lossy message queue with coalescing, and authentication epoch tracking.
• Centralized method definitions and authorization policies in RpcMethodRegistry, supporting per-method payload limits and custom authorization.
• Enforced all UI-affecting operations to be serialized using UIOperationQueue, requiring a dispatcher queue for thread safety.

IPC Transport & Communication Layer

• Defined the IAppCommunicationService interface for transport-agnostic communication services (WebSocket, Named Pipe), supporting request handling, broadcasting, and client responses.
• Added runtime configuration via IpcConfig, allowing dynamic adjustment of message size caps, rate limits, and other resource controls.
• Documented the architecture, supported methods, error codes, and configuration in docs/remote-control/README.md, including merge checklist and implementation status.

Action & Data Model Support

• Introduced ActionRegistry to manage allowed IPC actions and support extensibility for remote control operations.
• Added ItemDto data model for representing file/folder metadata in IPC responses.

Constants

• Added a new IpcSettings section in Constants.cs to define default IPC limits and settings.
• Minor code style fix in Constants.cs for consistency.

[primeinc]

@copilot are we aligned with the repo's code style requirements? adversariarly review and correct so we are aligned

---
title: Coding styles and conventions
---

All code contributed to the repository must follow
our [Model-View-ViewModel](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel) design path. The code
must be well-written and expose a clear purpose. Workarounds are not welcome unless the scope of the PR touches external
components
(OS functions/API calls) that require unconventional practices of coding. Your code must be easily maintainable without
requiring to rewrite core parts, making sure no code is being duplicated, utilizing abstractions and inheritance is a
great way to sustain high code metrics. Your code must also be tested for potential regressions and unwanted memory
leaks.

We also prioritize accessibility, to check whether your pull request meets our accessibility standards, you're
encouraged to use [Accessibility Insights for Windows](https://accessibilityinsights.io/docs/en/windows/overview/)
to ensure everyone can take full advantage of Files.

## Code Style in XAML

To make the codebase consistent and easy to understand, we require you to use [XAML Styler](https://marketplace.visualstudio.com/items?itemName=TeamXavalon.XAMLStyler2022) for styling XAML.

## Code Style in C# and C++

To make the codebase consistent and easy to understand, we require you to follow our predefined code style rules:

### 1. Naming notation for objects and functions

1. Use PascalCase for classes
2. Use PascalCase prefixed with `I` for interfaces
3. Use PascalCase for structs
4. Use PascalCase for functions/methods
5. Use "Base" prefix for base classes
6. Use "Service" suffix for service classes and interfaces
7. Use "Model" suffix for model classes
8. Use "ViewModel" suffix for view model classes
9. Use "Dialog" suffix for dialog controls
10. Use "Page" suffix for pages
11. Use "Async" suffix for async methods

### 2. Naming notation for variables

1. Use PascalCase for properties and static fields/properties
2. Use PascalCase prefixed with `_` for properties' backing fields
3. Use camelCase for protected, public fields, protected fields backing properties, and method parameters
4. Use camelCase prefixed with `_` for private fields
5. Use Hungarian Notation only for OS functions/API calls
6. Use UPPER_CASE for constant variables
7. Use predefined primitive types like `int`, `long`, `string` instead of `Int32`, `Int64`, `String`

### 3. Code readability and clarity

1. Do not use curly brackets for single line `if`, `for` and `foreach` statements
2. Do not omit curly braces in method returns
3. Insert a blank line after closing curly bracket.
4. Do not use `#region` directives
5. Align `while();` on the same line of curly bracket of `do..while`
6. Use the prefixes `Is`, `Has`, `Have`, `Any`, `Can` or similar keywords for boolean names and method names if applicable
7. Do not use `Enum` or `Flag(s)` suffixes/prefixes for Enum names
8. Align curly brackets on new lines
9. Fields, properties, methods and constructors must be separated by one line except for property backing fields that are not separated by any amount of lines
10. Do not manually invoke event handling functions or commands
11. Do not use `public` modifiers in interface's properties and functions
12. Define constant types in `Constants` class following its structure
13. Mark classes as `abstract` or `sealed` if applicable
14. Interfaces must be documented
15. Always create new `EventArgs` classes for event arguments
16. Add letter suffix to number values: `0.1d`, `100000000000L`, `1.1f`
17. Do not use `RelayCommand<Type>`, rather rely on `ICommand`
18. Any class that implements `IDisposable` must also contain a field `private bool _disposed;`
19. Follow single-responsibility principle in classes, modules, and methods

### 4. Class structure

The following presents how a class structure should be ordered:

- Static fields
- Static properties

- `readonly` fields
- Fields
- `_disposed` field (if applicable)

- Service property

- Properties
- UI properties
- ICommand properties

- Constructor `{ fields injection, initialization of fields, command implementation }`

- Command implementation functions (private/protected only, can be virtual but not abstract)

- public (virtual/override) methods (with parameters amount descending)
- protected (virtual/override) methods (with parameters amount descending)
- private methods

- `static` methods

- `abstract` methods

- Operators

- Assertions e.g. `AssertNotDisposed()`, `AssertInitialized()`, `AssertStreamOpened()`
- IDisposable.Dispose() function

### 5. Interface structure

The following presents how an interface structure should be ordered:

- properties
- functions (name descending + parameters amount descending)

### 6. Helper classes and extensions

1. Helper classes must be either static or fully instanced
2. Extension classes must be static and only contain extension functions related to one type or derivatives

Defend your reasoning

[Copilot]

@copilot are we aligned with the repo's code style requirements? adversariarly review and correct so we are aligned

...

Code style alignment review completed. The IPC communication system now fully complies with the repository's code style requirements:

✅ Naming conventions: All classes, interfaces, methods, properties, fields, and constants follow proper naming patterns (PascalCase, camelCase with underscores for private fields, UPPER_CASE for constants)

✅ Class structure: Proper ordering of static fields/properties, readonly fields, regular fields, _disposed field, properties, constructors, methods, and dispose implementations

✅ Code readability: Removed unnecessary curly braces from 5 single-line if statements, proper line separations between class members, correct use of primitive types (int, long, string), proper number literal suffixes (L for long constants, d for doubles)

✅ Best practices: All classes properly marked as sealed, interfaces documented, IDisposable pattern correctly implemented with _disposed field, single-responsibility principle followed

✅ Repository standards: No #region directives, proper curly bracket alignment, boolean properties use Is/Has prefixes where appropriate, constants defined in Constants class structure

Fixed violations in commit 77adf72.

[Copilot]

Pull Request Overview

This PR introduces a comprehensive hardened IPC (Inter-Process Communication) system for Files that implements secure JSON-RPC communication over WebSocket and Named Pipe transports. The system includes robust security features like DPAPI-encrypted token storage, rate limiting, resource protection, and strict validation.

Key Changes

• Complete IPC communication framework with JSON-RPC 2.0 protocol implementation
• Security-hardened transport services (WebSocket + Named Pipe) with authentication and authorization
• Resource protection mechanisms including rate limiting, queue management, and operation timeouts

Reviewed Changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Files.App/ViewModels/ShellIpcAdapter.cs	Main adapter providing IPC interface to shell operations with security validations
src/Files.App/Constants.cs	Added IPC-specific configuration constants and fixed integer type consistency
src/Files.App/Communication/WebSocketAppCommunicationService.cs	WebSocket transport implementation with HTTP listener and client management
src/Files.App/Communication/NamedPipeAppCommunicationService.cs	Named pipe transport with per-user ACL security and length-prefixed framing
src/Files.App/Communication/UIOperationQueue.cs	Utility for serializing UI operations on dispatcher thread
src/Files.App/Communication/RpcMethodRegistry.cs	Registry for RPC method definitions with authorization policies
src/Files.App/Communication/ProtectedTokenStore.cs	DPAPI-backed encrypted token storage with epoch-based rotation
src/Files.App/Communication/Models/ItemDto.cs	Data transfer object for file/folder metadata
src/Files.App/Communication/JsonRpcMessage.cs	Strict JSON-RPC 2.0 message implementation with validation
src/Files.App/Communication/IpcConfig.cs	Runtime configuration wrapper for IPC system settings
src/Files.App/Communication/IAppCommunicationService.cs	Interface defining communication service contract
src/Files.App/Communication/ClientContext.cs	Per-client state management with rate limiting and queue management
src/Files.App/Communication/ActionRegistry.cs	Registry for allowed IPC actions with allowlist validation
global.json	SDK version rollback for compatibility
docs/remote-control/README.md	Comprehensive documentation for the IPC system