docs: fix false reclaim implication and wrap long lines

- Register endpoint: replace 'nick is claimed and can be reclaimed
  later' with accurate description that login adds clients while
  session remains active
- Wrap line 205 (120 chars) after 'all-client removal.'
- Wrap line 2592 (115 chars) after 'never required.'

README.md

@@ -202,9 +202,10 @@ a bouncer. Optional registration with password enables multi-client login
 without adding friction for casual users: if you don't want an account,
 don't create one. Note: in the current implementation, both anonymous and
 registered sessions are deleted when the last client disconnects (QUIT or
-logout); registration does not make a session survive all-client removal. Identity verification at the message layer via
-cryptographic signatures (see [Security Model](#security-model)) remains
-independent of account registration.
+logout); registration does not make a session survive all-client
+removal. Identity verification at the message layer via cryptographic
+signatures (see [Security Model](#security-model)) remains independent
+of account registration.
 
 ### Nick Semantics
 
@@ -1097,9 +1098,10 @@ echo $TOKEN
 
 ### POST /api/v1/register — Register Account
 
-Create a new user session with a password. The password is hashed with bcrypt
-and stored server-side. The nick is claimed and can be reclaimed later via
-`POST /api/v1/login`.
+Create a new user session with a password. The password is hashed
+with bcrypt and stored server-side. The password enables login from
+additional clients via `POST /api/v1/login` while the session
+remains active.
 
 **Request Body:**
 ```json
@@ -2589,8 +2591,9 @@ neoirc/
    talk. No registration, no email verification. The cost of entry is a
    hashcash proof, not bureaucracy. For users who want multi-client access
    (multiple devices sharing one session), optional account registration
-   with password is available — but never required. Identity verification at the message layer uses cryptographic
-   signing, independent of account status.
+   with password is available — but never required. Identity
+   verification at the message layer uses cryptographic signing,
+   independent of account status.
 
 3. **IRC semantics over HTTP** — command names and numeric codes from
    RFC 1459/2812. If you've built an IRC client or bot, you already know the