Adopt .editorconfig as single source of truth for code style and add formatting CI gate

[craigsmitham]

Summary

The project currently relies on GraphZen.sln.DotSettings for all code style and formatting configuration, with only a minimal .editorconfig (just IDE0005). This creates ReSharper lock-in and means there is no formatting enforcement in CI. The modern .NET approach is to use .editorconfig as the portable, cross-tool single source of truth, with dotnet format as a CI gate.

Tasks

1. Expand .editorconfig with formatting and code style rules

Add comprehensive rules to the root .editorconfig:

• Core settings: indent_style, indent_size, end_of_line, charset
• C# formatting rules: csharp_new_line_*, csharp_indent_*, csharp_space_*
• Code style rules: csharp_style_expression_bodied_*, csharp_style_namespace_declarations, csharp_prefer_braces, csharp_style_var_*, etc.
• Naming conventions: dotnet_naming_rule.*, dotnet_naming_symbol.*, dotnet_naming_style.*
• Analyzer severities: dotnet_diagnostic.<ID>.severity for key rules

Use Microsoft's recommended defaults as a starting point, adjusted to match the project's existing conventions (expression bodies, file-scoped namespaces, trailing commas, etc.).

2. Migrate portable settings from .DotSettings to .editorconfig

Move all style/formatting rules that have .editorconfig equivalents out of GraphZen.sln.DotSettings. This includes:

• Expression body preferences
• File-scoped namespace preference
• Brace requirements
• Trailing comma preference
• Naming conventions (AST, QL abbreviations)

Keep .DotSettings only for ReSharper-specific features with no .editorconfig equivalent:

• Cleanup profiles ("GraphZen: Full Cleanup")
• Inspection excludes (obj/, TestResults/, .html)
• Structural search patterns
• Mandatory imports

ReSharper can export current settings to .editorconfig via Options > General Formatter Style > Edit .editorconfig interactively — use this as a starting point for the migration.

3. Add dotnet format --verify-no-changes to CI

Add a formatting check step to .github/workflows/ci.yml:

- name: Check formatting
  run: dotnet format --verify-no-changes --verbosity diagnostic

This is built into the SDK (no extra tools or licenses needed) and reads .editorconfig. It catches formatting and style violations before code is merged.

4. Keep dotnet jb inspectcode in CI for deeper analysis

dotnet format covers formatting and style, but dotnet jb inspectcode covers deeper concerns (code smells, complexity, ReSharper-specific inspections). Both should run in CI as complementary gates.

5. Optionally enable EnforceCodeStyleInBuild

In Directory.Build.props, consider adding:

<PropertyGroup>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup>

This makes code style violations surface as build warnings/errors (governed by severities in .editorconfig), giving developers immediate feedback during local builds — not just in CI.

Why

• Portability: .editorconfig works across ReSharper, Rider, Visual Studio, VS Code, and dotnet format — no single-tool lock-in
• CI enforcement: dotnet format is free and built into the SDK; no license needed for CI
• Developer experience: Formatting rules are enforced consistently regardless of which editor/IDE a contributor uses
• Reduced .DotSettings surface: Keeps ReSharper config focused on features only it provides