docs(agents): self-documenting code + <summary>/<remarks> guidance

.agents/rules/coding-style.md

@@ -9,7 +9,7 @@
 - Use `?.` null-conditional operator where applicable
 - Use `ArgumentNullException.ThrowIfNull` for null checks
 - Use `ObjectDisposedException.ThrowIf` for disposal checks
-- Use documentation comments with proper structure (`<summary>`, `<param>`, `<returns>`) for all public APIs
+- Use documentation comments with proper structure (`<summary>`, `<remarks>`, `<param>`, `<returns>`, `<exception>`, `<typeparam>`, `<inheritdoc/>`) for all public APIs. See [AGENTS.md](../../AGENTS.md) "Coding guidelines and style" for when to use each tag.
 - Avoid `var` — spell out types (exception: very long nested generic types)
 - Prefer low-allocation code patterns
 - Use `Array.Empty<T>()` or `[]` instead of `new T[0]` — avoids allocating a new empty array each time. In attribute arguments (e.g. `[Attr(new string[0])]`), `new T[0]` is acceptable because `Array.Empty<T>()` is not a compile-time constant.

AGENTS.md

@@ -15,6 +15,13 @@ This guide helps to get started with the Nethermind Ethereum execution client re
 - Keep changes minimal and focused — don't touch unrelated code
 - When fixing a bug, always add a regression test
 - Do not alter [src/bench_precompiles](./src/bench_precompiles/) or [src/tests](./src/tests/)
+- Prefer self-documenting code — clear names and structure should remove the need for most comments. Emit a comment only when it captures context that is not obvious from the code itself: the _why_ behind a non-obvious choice, an invariant, a workaround, an EIP/Yellow-Paper reference, a subtle edge case, etc. Comments that merely restate the code are noise — don't add them, and remove them when you encounter them.
+- For member-level documentation (methods, constructors, properties, types), prefer XML doc comments over in-line comments whenever the explanation applies to the member as a whole:
+  - `<summary>` — one or two sentences describing _what_ the member does from the caller's perspective: its contract, purpose, and what it returns/represents. Keep it short enough to be useful in IntelliSense; do not describe implementation details or rationale here.
+  - `<remarks>` — the longer-form explanation that does not belong in the summary. Use it for any of: algorithmic approach, design rationale, pre/postconditions and invariants, thread-safety guarantees, performance characteristics, side effects, edge cases, EIP / Yellow-Paper / spec references, and notable caveats for callers.
+  - Use `<param>`, `<returns>`, `<exception>`, and `<typeparam>` for parameter/return/exception/type-parameter specifics rather than stuffing them into `<summary>` or `<remarks>`.
+  - For interface implementations and overrides, prefer `<inheritdoc/>` (optionally with `cref=`) to propagate the contract from the base/interface instead of duplicating it. Add `<remarks>` only when the implementation introduces caller-visible behavior beyond the inherited contract.
+  - Reserve in-line comments for implementation-specific details that cannot reasonably live on the member header — e.g. why a particular branch is taken, why a value is computed this way at this exact spot, or a local workaround for a bug elsewhere.
 
 ---