docs: record LeyckerS#150 in the changelog and authors

@shard872's LeyckerS#150 closes LeyckerS#116: a full destination disk is now a run-level
fatal condition rather than an ordinary per-file error.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: LeyckerS

AUTHORS.md

@@ -29,6 +29,7 @@ first contribution:
 | [@PomPomSaturin](https://github.com/PomPomSaturin) | restored the dependency upper bounds without moving the floors, added a tested `constraints.txt`, and wrote the CI job that fails when a requirement has no upper bound — so they cannot be lost a third time (#136); made both worker gathers collect their failures instead of aborting on the first one, and name the worker that failed (#143) |
 | [@8nt0n](https://github.com/8nt0n) | made the proxy chip tell the truth before a run starts, distinguishing "no file" from "file with nothing usable in it", and extracted the line parser so the status check and the real load cannot disagree (#132) |
 | [@Allen58562](https://github.com/Allen58562) | made Stop interrupt transfers already in flight instead of waiting for them to finish, via a registry of per-download kill events signalled with `call_soon_threadsafe`, and gave a user-initiated stop its own `stopped` status so it is no longer counted as a stall kill and re-queued (#149) |
+| [@shard872](https://github.com/shard872) | made a full destination disk a run-level fatal condition instead of a per-file error — errno-based `ENOSPC` detection, a shared abort both front-ends observe, the folder and shortfall named in the live log, `.tmp` files preserved for resume, and a `memoryview` write loop so a short write on a nearly-full disk cannot truncate silently (#150) |
 
 Dependabot handles the dependency and action bumps.
 

CHANGELOG.md

@@ -14,6 +14,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [Unreleased]
 
 ### Fixed
+- **A full destination disk no longer burns bandwidth it cannot write.** `ENOSPC`
+  was caught by the same catch-all that handles ordinary transfer errors, so the
+  queue kept going and the retry machinery kept re-fetching data that could never
+  land — measured on the run that opened the issue: 46 files, each downloading
+  for ~236s before failing, ~12 GB pulled and discarded, with nothing on screen
+  saying why. The first `ENOSPC` is now detected by `errno` and published as a
+  run-level fatal state; new queue intake and retries stop, active transfers
+  unwind at their next write boundary, and the live log names the folder and the
+  shortfall. Interrupted files keep their `.tmp` and stay resumable, and only the
+  URL that triggered it is recorded as failed — files stopped as a consequence
+  are reported `aborted` rather than each being blamed individually. Writes now
+  loop over a `memoryview`, because a short write on a nearly-full disk returns a
+  count instead of raising and would otherwise truncate the file silently.
+  Thanks to [@shard872](https://github.com/shard872) (#116, #150).
 - **Stop now interrupts downloads already in flight.** `Engine.stop()` set the
   stop flag and closed Chrome, but a transfer that had already started ran to
   completion — on a large file the button appeared to do nothing for minutes.