chore: clarify sentence-per-line style guide

Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>

Author: yjkellyjoo

CLAUDE.md

@@ -57,7 +57,7 @@ The `prebuild` npm hook runs automatically before `build` and does three things,
 
 ## Content conventions (from CODING.md)
 
-- **Wrap long lines** with newlines — keeps git diffs small and reduces merge conflicts.
+- **One sentence per line** — put a newline after every sentence instead of hard-wrapping at a fixed width; keeps git diffs small and reduces merge conflicts.
 - **Minimize unrelated edits** (e.g. don't reflow a whole paragraph to fix one typo) for the same reason.
 - **`Swarm` vs `swarm`**: capital `Swarm` = the project / main network; lowercase `swarm` = a swarm of bee nodes (Bee supports running multiple). Capital `Bee` = the Go client; lowercase `bee` = any Swarm-protocol client.
 - **Version bumps**: automated by the `update-openapi` workflow on each new stable Bee release (literal find-and-replace of the semver in the install docs). Only bump by hand for out-of-band corrections, across the whole `docs/` folder.

CODING.md

@@ -1,33 +1,24 @@
 # Coding guide
 
-- Please wrap long lines using `newline` characters, so that the `git`
-  line diffs result in fewer merge conflicts.
+- Write each sentence on its own line: put a newline after every sentence, rather than hard-wrapping lines at a fixed column width.
+  This keeps `git` line diffs small and produces fewer merge conflicts, without the awkward mid-sentence breaks that fixed-width wrapping causes.
 
-- Don't change things unnecessarily (e.g. if you reindent an entire
-  paragraph when you're fixing a single typo, then you unnecessarily
-  increase the probability for merge conflicts).
+- Don't change things unnecessarily (e.g. if you reindent an entire paragraph when you're fixing a single typo, then you unnecessarily increase the probability for merge conflicts).
 
-- Prefer `npm ci` instead of `npm install`, and only include the
-  `package-lock.json` file in your commit when you know what you are
-  doing. For further explanation see this
-  [stackoverflow question](https://stackoverflow.com/questions/48524417/should-the-package-lock-json-file-be-added-to-gitignore).
+- Prefer `npm ci` instead of `npm install`, and only include the `package-lock.json` file in your commit when you know what you are doing.
+  For further explanation see this [stackoverflow question](https://stackoverflow.com/questions/48524417/should-the-package-lock-json-file-be-added-to-gitignore).
 
 ## Swarm vs. swarm, and uppercasing in general
 
-`Swarm`, with a capital, refers to the project and the main network,
-e.g.:
+`Swarm`, with a capital, refers to the project and the main network, e.g.:
 
  > Swarm uses the content hashes as addresses
 
  > As of today, the Swarm mainnet consists of `n` number of nodes
 
-`swarm`, in lower case, refers to a swarm of bee nodes. Note that the
-Bee client supports running/forming multiple Swarm swarms, i.e. you
-can even run your own!
+`swarm`, in lower case, refers to a swarm of bee nodes.
+Note that the Bee client supports running/forming multiple Swarm swarms, i.e. you can even run your own!
 
  > when your node joins the designated swarm
 
-[`Bee`](https://github.com/ethersphere/bee), with a capital, refers to
-a specific bee client, written in the `go` programming language, while
-`bee`, in lower case, refers to any worker that can join a swarm
-(e.g. any client implementation that speaks the Swarm protocol).
+[`Bee`](https://github.com/ethersphere/bee), with a capital, refers to a specific bee client, written in the `go` programming language, while `bee`, in lower case, refers to any worker that can join a swarm (e.g. any client implementation that speaks the Swarm protocol).