Bound Tokio limited-helper cleanup cost

Author: eldryoth

CHANGELOG.md

@@ -23,6 +23,9 @@
   buffers and RAII-wiped read-all allocations that also cover cancellation.
 - Bounded Tokio limited-helper over-read to one lookahead byte and documented
   the adjacent-frame contract.
+- Capped Tokio limited-helper eager allocation at 8 KiB and made per-read
+  staging cleanup proportional to bytes received while retaining full RAII
+  cleanup on cancellation and drop.
 - Pinned documented release-tool installs to the audited current versions,
   including cargo-nextest `0.9.140` and cargo-fuzz `0.13.2`.
 - Deferred the stronger RISC-V RVV proof and backend-admission review to

crates/base64-ng-tokio/README.md

@@ -36,7 +36,9 @@ or validate a final partial quantum.
 Read-all helper allocations are RAII-wiped on success, error, and cancellation.
 Limited helpers consume no more than the configured limit plus one lookahead
 byte used to detect overflow. Use a separately bounded reader or a streaming
-adapter when an adjacent frame's first byte must remain unread.
+adapter when an adjacent frame's first byte must remain unread. Their eager
+allocation is capped at 8 KiB so cleanup work stays proportional to accepted
+input rather than the caller's maximum alone.
 
 ```rust
 use base64_ng::STANDARD;

crates/base64-ng-tokio/src/lib.rs

@@ -39,7 +39,7 @@ pub use readers::{DecoderReader, EncoderReader};
 use base64_ng::{Alphabet, Engine};
 use tokio::io::{self, AsyncRead, AsyncReadExt, AsyncWrite, AsyncWriteExt};
 
-const READ_ALL_EAGER_CAP: usize = 1024 * 1024;
+const READ_ALL_EAGER_CAP: usize = 8192;
 
 /// Reads all bytes from `reader`, encodes them, and writes the encoded output.
 ///
@@ -287,6 +287,6 @@ where
         }
 
         input.0.extend_from_slice(&chunk.0[..read]);
-        wipe_bytes(&mut chunk.0);
+        wipe_bytes(&mut chunk.0[..read]);
     }
 }

docs/ASYNC.md

@@ -17,7 +17,10 @@ suspension point. Their initialized bytes and spare capacity are wiped on
 success, I/O error, or future cancellation. Limited helpers request at most the
 remaining allowance plus one lookahead byte. Generic `AsyncRead` cannot return
 that lookahead byte to the source; callers that must preserve adjacent framed
-input should provide an already bounded reader or use a streaming adapter.
+input should provide an already bounded reader or use a streaming adapter. The
+limited helpers cap eager allocation at 8 KiB and wipe only the bytes filled by
+each successful read; their RAII guards still wipe complete live allocations
+and the complete staging array on cancellation or drop.
 
 ## Current Status
 

release-notes/RELEASE_NOTES_1.3.7.md

@@ -26,6 +26,9 @@ the `base64-ng` crate family.
   wipe through RAII on success, error, and cancellation.
 - Limited oversized-input detection to one lookahead byte and documented the
   adjacent-frame behavior for generic `AsyncRead` sources.
+- Capped limited-helper eager allocation at 8 KiB and made per-read staging
+  cleanup proportional to received input while retaining full cancellation
+  cleanup.
 - Pinned documented release/deep-check tool versions to the current audited
   releases, including cargo-nextest `0.9.140` and cargo-fuzz `0.13.2`.
 - Scheduled the stronger RISC-V RVV proof and backend-admission review for