feat(protocol): add optional STATUS_ERROR_DETAIL rejection reason (2.21.0)

Today a server rejection sends a bare STATUS_ERROR and the reason only
reaches the server log, so the client cannot say why a transfer was
refused.  Add an optional, bounded server->client error-detail frame:

  - Status gains STATUS_ERROR_DETAIL appended LAST so existing wire
    values are unchanged.
  - send_error_detail(fd, msg) sends STATUS_ERROR_DETAIL followed by the
    existing length-prefixed string primitive, slicing over-long messages
    to MAX_ERROR_DETAIL_BYTES (4096).
  - receive_status() (and the timed/keepalive status readers) always
    consume the detail body and map the status back to STATUS_ERROR,
    capturing the text into a thread-local buffer exposed by
    protocol_last_error(); a bare STATUS_ERROR leaves it cleared.  Every
    existing call site keeps working and the stream cannot desync.
  - Upgrade the daemon module gate / config validation (config.c), the
    final transfer failure (server.c) and receiver-side path/node
    validation (file_receive.c) to send a concrete reason; surface it on
    the client in client_send.c/config.c.
  - Bump PROTOCOL_VERSION to 2.21.0 (CMake VERSION, CHANGELOG, docs) and
    update the pinned config wire golden hash / CLI-version tests.
  - Add tests/test_protocol_error.c covering mapping+capture, the
    over-long bound, bare-error clearing, and thread-locality.

CHANGELOG.md

@@ -23,6 +23,26 @@ run the same version because the handshake is strict.
   shared NAT/proxy still share a single per-host budget and lockout, which is
   documented.
 
+## [2.21.0] - 2026-09-13
+
+### Added
+
+- Optional server→client rejection detail (protocol 2.21.0). A rejected
+  operation may now carry a bounded human-readable reason via
+  `STATUS_ERROR_DETAIL` instead of a bare `STATUS_ERROR`, so the client can
+  report *why* the server refused (daemon module gate, config validation,
+  receiver-side path/node validation). `receive_status()` transparently maps the
+  new status back to `STATUS_ERROR` for every existing call site and captures
+  the reason into a thread-local buffer exposed by `protocol_last_error()`. The
+  detail body is always consumed, so the stream cannot desynchronize, and
+  messages are sliced to `MAX_ERROR_DETAIL_BYTES` (4096) on send.
+
+### Changed
+
+- `receive_incremental_check()` (the per-file `STATUS_CHECK` fast path) is split
+  into small static helpers with a short linear orchestrator. Pure refactor: the
+  wire byte stream and all cleanup are unchanged.
+
 ## [2.20.0] - 2026-09-13
 
 ### Security