Replace CheckNamespace CI exclusion with a Roslyn analyzer that enforces domain-driven namespaces

## Problem

The `CheckNamespace` ReSharper inspection flags **~4,444 folder-namespace mismatches** in the codebase. Since namespaces in this project are domain names, not folder paths (e.g. `DCL.Ipfs` lives in the `DCL.Network` assembly), most of these warnings are intentional and noise.

PR #9396 addresses this by excluding `CheckNamespace` from the CI warning ratchet entirely, which stops the noise but also means the linter can no longer catch *actual* namespace problems — cases where a type genuinely ended up in the wrong namespace.

We need a better long-term solution that can distinguish between intentional domain-driven mismatches and actual mistakes.

## Proposed Solution

### Build a custom Roslyn analyzer

Create a Roslyn analyzer (DiagnosticAnalyzer + optional CodeFixProvider) that replaces the blanket `CheckNamespace` inspection with a domain-aware namespace check. The analyzer should:

1. **Derive the expected namespace from the domain path, not the folder path.** Define a mapping (e.g. via an `.editorconfig` property, an attribute, or a convention file) that associates directory subtrees with their expected domain namespace roots. For example:
- `Explorer/Assets/DCL/Infrastructure/SceneLifeCycle/` → `ECS.SceneLifeCycle`
- `Explorer/Assets/DCL/Network/Ipfs/` → `DCL.Ipfs`

2. **Flag only genuine mismatches.** If a file's namespace matches its domain mapping, it passes — even if the folder path doesn't match. If it matches *neither* the domain mapping nor the folder path, emit a diagnostic.

3. **Suggest the correct namespace via a code fix.** The CodeFixProvider should offer a quick-fix that sets the namespace to the domain-expected value, making it easy for developers to resolve real issues from their IDE.

4. **Integrate with CI.** Once the analyzer is mature enough, re-enable namespace checking in the warning ratchet — this time backed by the domain-aware rules instead of ReSharper's folder-based `CheckNamespace`.

### Key design considerations

- The domain-to-namespace mapping should be easy to maintain — ideally a single config file or set of assembly-level attributes.
- The analyzer should handle the existing conventions: not every folder is a namespace provider (e.g. `Scripts`, `MainScripts`, `Assets` are skipped), and deeply nested folders may not contribute to the namespace.
- Consider aligning with the rules already documented in `docs/code-style-guidelines.md` § Namespaces.

## Context

- PR #9396 excludes `CheckNamespace` from the CI ratchet as an interim fix.
- `docs/code-style-guidelines.md` already documents that namespaces are domain-driven and that `// ReSharper disable once CheckNamespace` suppressions are forbidden.
- The codebase has ~4,444 `CheckNamespace` warnings in the current dev baseline (~23% of all warnings).

Requested by Juan Ignacio Molteni [Dalkia] via Slack