Drop the formatting step, which spent minutes agreeing with the build

`dotnet format --verify-no-changes` re-analysed the whole solution before the build did, to
reach a verdict the build reaches on its own: IDE0055 is an error in .editorconfig,
EnforceCodeStyleInBuild is on and warnings are errors, so a misformatted file fails the
build step. What the separate step bought was hearing about it a few minutes earlier, and
it charged those minutes on every run.

Checked rather than assumed, because the whole justification rests on it: appending a
badly-spaced member to a source file produces three `error IDE0055` lines and a failed
build with no format step in sight.

Three places said the old arrangement out loud and would now be wrong on their own — the
comment on the IDE0055 line, the conventions list in the README, and a note in
platform-flags telling people to run dotnet format before pushing or CI would fail them.
They say the build enforces it now. dotnet format is still how to fix what the build
complains about; it just no longer gates anything.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.editorconfig

@@ -91,7 +91,9 @@ dotnet_naming_style.camel_case_style.capitalization = camel_case
 
 #### Diagnostics ####
 
-# Formatting violations fail the build; `dotnet format --verify-no-changes` gates CI.
+# Formatting violations fail the build, and that is now the whole of the enforcement: CI
+# has no `dotnet format --verify-no-changes` step any more, because this line already
+# fails it.
 dotnet_diagnostic.IDE0055.severity = error
 
 # ConfigureAwait is not meaningful in ASP.NET Core (no SynchronizationContext). It IS